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GLOSSARY 



active foreground program: a foreground program is active 
If It is resident In memory, connected to Interrupts, or 
In the process of being entered Into the system via a 
!XEQ control command. 

background area: that area of core storage allocated to 
batch processing. This area may be checkpointed for 
use by foreground programs. 

background program: any program executed under Monitor 
control In the background area when no Interrupts are 
active. These programs are entered through the batch 
processing Input stream. 

batch processing: a computing technique In which similar 
programs are grouped together and processed or exe- 
cuted in a single run so as to effect efficient utiliza- 
tion of the computer. 

channel status table: a table of five words per SYSGEN- 
defined I/O channel that reflects the hardware condi- 
tion of each I/O channel. 

checkpointed job: a partially processed background job 
that has been saved In secondary storage along with 
all registers and other "environment" so that the job 
can be restarted at its Interrupted point. 

clock counter: a memory location that records the progress 
of real time or Its approximation, by accumulating 
counts produced by a (clock) count pulse interrupt. 

close: terminating the use of an item (such as a file) and 
performing certain clean up operations to provide for 
its future reuse or the reuse of its resources. 

control command: any control message other than a key-In. 
A control command may be Input via any device to 
which the system command Input function has been 
assigned (normally a card reader). 

control message: any message received by the Monitor that 
is either a control command or a control key-In. 

count zero interrupt: an interrupt level that is triggered 
when an associated (clock) count pulse Interrupt has 
produced a zero result in a clock counter. 

dedicated memory: core memory locations reserved by the 
Monitor for special purposes, such as Interrupts and 
real-time programs. 

device-file number: a logical method of referring both to 
a physical peripheral device and to a collection of in- 
formation about the device. The device file number 
indicates the order In which devices are initially de- 
fined at SYSGEN. For example, the first device 
defined must always be a keyboard printer (DFN 1). 



device name: an Identifier used at SYSGEN time for an 
actual physical I/O device that is composed of two 
elements: a device type which is a two-character code 
for a particular class of peripheral devices, and a de- 
vice number which is a two-digit hexadecimal repre- 
sentation of the physical unit number associated with 
device. 

device unit number: an integer value coded into a 

FORTRAN IV program to reference peripheral devices. 
Standard device unit numbers can be equated to device 
file numbers (see above) either at SYSGEN time or 
through ! ASSIGN commands. 

dictionary: a directory of names and addresses of files or 
other catalogs on a random access device that enables 
the system to locate an item when given only Its name. 

disabled: the condition of an Interrupt level wherein the 
level may advance from the armed to the waiting state 
when triggered by an interrupt pulse, but the level 
cannot cause a program interruption until It is enabled; 
it thus remains in the waiting state until it Is allowed 
to interrupt the program. 

disarmed state: the state of an Interrupt level that cannot 
accept an Interrupt Input signal. 

disk pock: a secondary storage system of removable rotating 
memory. For most RBM purposes, disk pack and RAD 
are synonymous unless otherwise noted. 

enabled: the condition of an interrupt level wherein 
the level is not inhibited from advancing from the 
waiting state to the active state except for priority 
considerations. 

end action; that action that takes place at the completion 
of an I/O operation. This usually includes the entry 
of a special routine that was specified when the re- 
quest was made. 

end record: the last record to be loaded in an object 
module or load module. 

error severity level code: a code Indicating the severity 
of error noted by the processor. This code Is con- 
tained in the final byte of an object module. 

execution location: a value replacing the origin of a 
relocatable program that changes the address at which 
program loading is to begin. 

external Interrupt: one of the class of Interrupts that are 
associated with special systems equipment. These 
Interrupts are "external" to the basic computer sys- 
tem and are associated with functions that are de- 
fined according to the requirements of a particular 
Installation. 



VIII 



external interrupt inhibit: the bit, in the program status 
doubleword, that indicates whether (if 1) or not (if 0) 
all external interrupts ore inhibited. 

external reference: a reference to a declared symbolic 
name that Is not defined within the module in which 
the reference occurs. An external reference can be 
satisfied only if the referenced name Is defined by an 
external load item in another module. 

file control table: contains Information about all device 
files in the RBM system and is Indexed by device-file 
number. 

file name: a name for a permanent file that Is defined 
either at SYSGEN or later through the RAD Editor. 

foreground area: that portion of memory dedicated speci- 
f I dally for RBM, service routines, and foreground 
programs. 

foreground program: a program that executes in the 

foreground area of core and can utilize all privileged 
services. 

foreground task: a body of procedural code that is associ- 
ated with (connected to) a particular Interrupt. 

GO file: a RAD file of Relocatable Object Modules 
(ROMs) formed by a processor. This Is a default 
input file when no file name Is specified. 

granule: the minimum physical amount of data transferred 
in a read or write operation from/to random RAD or 
disk pack files . A granule Is usually synonymous with 
a sector on a device, but may be defined (on a file 
basis) to be equivalent to a partial sector, one sector, 
or several sectors. 

Idle state: the state of the Monitor when it is first loaded 
into core memory or after encountering a !FIN control 
command. The Idle state Is ended by means of an 
S key-In. 

inhibited Interrupt: a condition of an Interrupt that pro- 
hibits it from entering the active state. 

input/output interrupt: an interrupt triggered by the stan- 
dard I/O system of the computer. 

installation control command: any control command used 
during System Generation to direct the formatting of 
a Monitor system. 

internal interrupt: one of the class of Interrupts that are 
supplied with a standard computer system, or are op- 
tional additions associated with dedicated functions 
(such as power fall -safe). These interrupts are 
"internal" to the basic computer system. 

interrupt trigger signal: a signal that is generated, either 
Internal or external to the CPU, to interrupt the nor- 
mal sequence of events in the central processor. 



I/O control table: a table containing the device-specified 
input/output control doublewords and other Information 
necessary for RBM I/O services. There is a one-to-one 
correspondence between the I/O control table and file 
control table. 

I/O control subtable: same as I/O control table except 
that the subtable is RAD specific. 

library input: Input from the device to which the LI 
(library input) operational label is assigned. 

library load module: a load module that may be combined 
(by the Overlay Loader) with relocatable object mod- 
ules, or other library load modules, to form a new 
executable load module. 

link editing: the process of combining separately compiled 
or assembled program modules, relocating them, link- 
ing them to defined library routines, and producing 
an absolute executable load module. 

loading: the process of reading an executable program (see 
link editing above) from secondary memory to absolute 
locations In main memory. 

load map: a listing of significant information pertaining to 
the storage locations used by a program. 

load module: an executable program formed by using 
Relocatable Object Modules and/or library object 
modules as source Information. 

logical device: a peripheral device that is represented In 
a program by an operational label (e.g., BI or BO) 
rather than by a specific physical device name. 

memory protection: the use of the optional protection fea- 
ture that keeps unprotected background memory from 
altering protected foreground meaning. 

memory write lock: a one-bit write-protect field optionally 
provided for each 256-word page of core memory 
addresses. 

Monitor: a program that supervises the processing, loading, 
and execution of other programs. 

nonresident foreground program: a foreground program 

explicitly called from secondary memory that resides In 
the nonresident foreground area of core memory during 
execution. The space thus occupied Is considered 
"active" and is protected by the Monitor from inter- 
ference by other activities. 

object deck: a card deck comprising one or more object 
modules and control commands. 

object language: the standard binary language In which 
the output of a compiler or assembler is expressed. 

object module: the series of records containing the 
load information pertaining to a single program 



or subprogram- Object modules serve as input to 
the Overlay Loader. 

open: the preparing of an item (such as a file) for initial 

use- 
operational label: a symbolic name used to identify a logi- 
cal system device. 

operational label table: there are two tables: one for 
foreground and one for background. The tables con- 
tain the two-character operational labels that are used 
for reference by the RBM service routines and connect 
an operational label to a device file number. 

option: an elective operand in a control command or pro- 
cedure call. 

Overlay Loader: a processor that links and absolutizes 
elements of programs. 

overlay program: a segmented program In which the seg- 
ment currently being executed may overlay the core 
storage area occupied by a previously executed 
segment. 

OV file: a RAD file that contains an executable program 
formed by the Overlay Loader if a program file name 
was not specified at load time. Used primarily to test 
new programs or new versions of programs. This is a 
default file when no output file is specified. 

physical device: a peripheral device that is referred to by 
a "name" specifying the device type, I/O channel, 
and device number (also see "logical device"). 

postmortem dump: an optional listing of the contents of a 
specified area of core memory, usually following the 
abortive execution of a background program. 

primary reference: an external reference that must be 

satisfied by a corresponding external definition (capa- 
ble of causing loading from the System Library). 

priority level: priority level of a task is dependent on the 
position of its associated hardware interrupt in the 
priority chain. 

RAD/disk areas: the allocation and definition of a RAD 
into specific areas during SYSGEN, each of which is 
labeled with a two-character mnemonic to expedite 
file management. 

Rapid Access Data (RAD) storage system: a secondary stor- 
age system of rotating memory. For most RBM pur- 
poses, RAD and disk pack are synonymous unless 
otherwise noted. 

real-time processing: data processing designed so that the 
results of the operations are made available in time to 
influence some process being monitored or controlled 
by the computer system. 



reentrant: that property of a program or subroutine that 
enables it to be interrupted at any point, employed by 
another user, and then resumed from the point of 
interruption. Reentrant programs are often found where 
there is a requirement for a common store of public 
routines that can be called by any user at any time. 
The process is control led by the Monitorwhich preserves 
the routine's environment (registers, working storage, 
control indicators, etc.) when it Is Interrupted and 
restores that environment when the routine is resumed 
for its Initial user. A reentrant routine never stores 
any intermediate values within itself. 



Relocatable Object Module: a program or subprogram that 
may be relocated and link edited to operate anywhere 
In core; that Is, does not have absolue addressing. 

resident foreground program: a foreground program that is 
automatically loaded into a fixed area of foreground 
core memory every time the system Is booted In. 

secondary reference: an external reference that may or 
may not be satisfied by a corresponding external 
definition (not capable of causing loading from the 
system library). 

secondary storage: any rapid access storage medium other 
than core memory (e.g. , RAD or disk pack). 

segment loader: a Monitor routine that loads overlay seg- 
ments from RAD storage at execution time. 

semi resident foreground program: a foreground program 
explicitly called from secondary memory that re- 
sides in the resident portion of core memory during 
execution. 



service routines: Monitor-supplied services and opera- 
tions that can be called by an executing foreground 
program, or else by an executing background program 
(except for certain privileged function dedicated to 
foreground use). 

source deck: a card deck comprising a complete program 
or subprogram In symbolic EBCDIC format. 



source language: a language used to prepare a source 
program (and therefrom a source deck) suitable for 
processing by an assembler or compiler. 



symbolic Input: Input from the device to which the 
SI (symbolic input) operational label Is assigned. 



symbolic name: an identifier that is associated with some 
particular source program statement or item so that 



symbolfc references may be made to It even though temporary files: those files that exist only until the current 

its value may be subject to redefinition. job step ends. They may, or may not, have existed 

prior to the start of the fob. 

system library: a group of standard routines in relocatable 

object language format, any of which may be included Temp Stack: an area of memory optionally created by 

in a program being created. the Overlay Loader for a user program and used by the 

Monitor and System Library routines. 

Task Control Block (TCB): part of the load module that 

contains the area required for context storage. The unsolicited key-in: information entered by the operator via 

TCB is task-associated. a keyboard in response to a Control Panel interrupt. 



1. INTRODUCTION 



RBM CHARACTERISTICS 

The Sigma 2/3 Real-Time Batch Monitor (RBM) is the major 
control element in the operating system. It supervises and 
services simultaneous foreground programs and -background 
batch programs without interfering with the real-time re- 
sponse capability of the foreground. 



NONRESIDENT SECTION 

The nonresident part of RBM consists of the system initiali- 
zation portion that is loaded at the time the system is cre- 
ated. Monitor service routines, and device-dependent I/O 
routines for which a response is not critical. It selects the 
optional features of RBM and initializes the input/output 
constants. 



RESIDENT SECTION 

The resident portion of RBM consists of the following parts: 

• Several independent tasks that are connected to the 
hardware interrupts (e.g., the real-time tasks). The 
tasks are not reentrant. They can communicate with 
each other and may use some of the Monitor service 
routines. 

• Several reentrant Monitor service routines that can be 
used by any task In the system. These ore described 
in Chapter 4. 

• Standard system constants and tables (see Appendix B). 

• Input/output constants and status information. 



SYSTEM ENVIRONMENT 

In addition to the Monitor itself, the hardware-software 
environment of the operating system consists of the following 
major elements: 

• Sigma 2/3 hardware including (a) the required system 
RAD, (b) the selected number of hardware interrupts 
connected to various foreground tasks in user-determined 
priority sequence, (c) dedicated and commonly shared 
I/O devices, and (d) optional secondary storage modules. 

• Partitioned core memory (see Figure 1) divided Into 

o A protected foreground area reserved for (1) resi- 
dent real-time foreground programs, (2) a single 
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nonresident foreground program, (3) Monitor tasks 
that must respond to high-priority interrupts, 
(4) Monitor service routines, and (5) optional 
routines (such as a Public Library) that are used 
by both foreground and background programs. 

o An unprotected background area used by back- 
ground (non-real-time) processors, translators, and 
batch users' programs, and occasionally by fore- 
ground programs requiring temporary use of addi- 
tional memory. (In this case the foreground will 
checkpoint the background.) 

The system RAD, allocatable into permanent and tem- 
porary files. The permanent files contain all of the 
background RBM processors such as Basic FORTRAN IV, 
Extended Symbol, RAD Editor, etc., plus RBM itself. 
They may also contain user data and optional resident 
and nonresident foreground programs that can be called 
into protected memory for processing. Temporary files 
are normally used as intermediate scratch areas by 
processors or user programs. 

Up to 137 (107 for Sigma 3) user foreground tasks that 
can be connected to interrupts. Examples of foreground 
tasks are process control operations, real-time data ac- 
quisition and control, and low-speed telemetry applica- 
tions. The RBM Control Task is connected to the lowest 
priority hardware interrupt in the system so that no 
background processing can delay foreground tasks. 

Overlay Loader for linking and absolutizing segmented 
foreground and background programs that enables back- 
ground processors and user programs to overlay them- 
selves in core storage, and thus permitting programs of 
virtually unlimited size to be executed. 



FOREGROUND (High-level Priority Response) 

Within the framework of the user-determined hardware 
interrupt priorities, foreground programs or tasks operate as 
independent entities, and the Monitor generally makes no 
attempt to interject itself between these tasks and their real- 
time functions. The Monitor services the foreground only 
on request, such as a call to one of the Monitor service rou- 
tines. The principal foreground services of the Monitor are to 

• Respond to I/O Interrupts. 

• Respond to an operator's console request (such as 
queuing). 

• Supervise RAD file activity. 

• Optionally, supply a software version of multiply/ 
divide functions for configurations without multiply/ 
divide hardware. 



For RBM purposes, RAD and disk pack are synonymous 
unless specifically stated otherwise. 



• Load a foreground program into memory from the RAD 
on request. 

• Provide the foreground with standard constants (see 
Appendix B). 

• Make available a "mailbox" area of 32 cells of mem- 
ory for communication between two or more foreground 
programs. 

The interrupt priority sequence (described in detail In the 
Xerox Sigma 2 and Sigma 3 Computer Reference Manuals) is 
the basis for the priority level of tasks in the RBM system. 
That is, the priority level of a task is dependent on the 
position of the associated hardware interrupt in the inter- 
rupt priority chain. Background jobs in the system all have 
the same priority level. A background job is not connected 
to any interrupt level in the system, i.e., its priority is be- 
low all hardware interrupt levels and is processed serially. 



BACKGROUND (Low-Uvei, No Priority) 

The primary function of the Monitor is to supervise and con- 
trol all those operations that take place in the unprotected 
background area by the following means: 

1. Use only available foreground idle time for back- 
ground processing. 

2. Interpret control functions from control command card 
Images via the Job Control Processor. 

3. Supervise the loading and execution of all back- 
ground jobs and activities In unprotected memory. 

4. Provide simple background scheduling (first-in, 
first-out). 

5. Provide I/O services for the background job stack. 

6. Inform the operator on the status of peripheral device 
operations. 

7. Test all background operations and processes for fore- 
ground protection violations and prevent the background 
from altering or delaying foreground response or from 
using dedicated I/O devices. 



Monitor processors and permanent user processors may be 
loaded onto permanent RAD files and then executed by 
control command. Programs may also be loaded onto tem- 
porary RAD files for the duration of the present job. 



All programs must exist on the RAD In absolute core image 
form for execution. Relocatable programs, consisting of 
a root and one or more overlay segments linked by ex- 
ternal references, must be created by the Overlay Loader 
to link all modules and create the proper overlay struc- 
ture for execution. 



RBM Characteristics 



It is possible to create programs consisting of a root and one 
or more overlay segments through use of the Absolute Loader 
if there are no external references (see the lABS command in 
Chapter 2 for other restrictions). 

Two levels of logical (rather than physical) device refer- 
encing are provided, enabling system configurations to 
change or expand without reprogrommlng. Further, through 
many device-independent features and use of standard media 
formats. Input and output can be directed to card equipment, 
paper tape equipment, or magnetic tape without changes In 
the user's program. 

For maximum flexibility and control of Input/output, the 
user can optionally specify his own lOCDs and order bytes, 
perform Independent error recovery, and be informed by 
RBM when an I/O operation has terminated. Alternatively, 
for greater ease of programming and device independence, 
the RBM will create the lOCDs and order bytes and per- 
form standard error checking and recovery. 

When multiprogramming with foreground tasks and back- 
ground jobs, the foreground has access to ail privileged In- 
structions In the Sigma 2/3 computers. The background is 
checked by both hardware and software to provide complete 
protection of a foreground program's use of core memory and 
peripheral operations. 



SECONDARY STORAGE MANAGEMENT 

The RBM operating system provides use of the RAD or disk 
packs for 

• Temporary and permanent fi las. 

• User and system files. 

• Sequential files (pseudo tape, where RBM performs all 
bookkeeping). 

• Random-access files (RBM performs I/O transfer and con- 
trols file limits, but user controls relative addressing). 

RAD/DISK PACK AREAS 

The concept of RAD areas Is a convention created primarily 
to offer a scheme to expedite file management. RAD areas 
ore allocated during system initialization (see RAD Alloca- 
tion In Chapter 11) and are labeled with two alphanumeric 
characters, usually from the following list: 



Certain labels of the list above have the special meaning 
given In Table 1. 

Table 1 . RAD/Disk Areas 



Mnemonic 



SP' 



SD^ 



SL^UL 



UP 



BT' 



CP^ 



Xn 



Meaning 



System Processor area. Contains RBM and 
user-selected processors from the list given 
in Table 5 (the Overlay Loader Is a man- 
datory processor). This area Is searched 
whenever either a system processor or user 
processor Is requested. 

System Data area. Contains files neces- 
sary for the execution of RBM, 

System Library and User Library areas. 
These are the only areas from which the 
Overlay Loader will load library routines. 

User Processor area. Contains resident 
foreground programs, foreground tasks, 
nonresident programs, semi resident pro- 
grams, and background programs. Only this 
area and SP area are searched when a pro- 
cessor Is requested. 



Background Temp area, 
tion of temporary files. 



Used for alloca- 



Checkpolnt area. Used to store the back- 
ground environment when a background 
program Is checkpointed by a foreground 
process. 

Xn areas are similar to Dn areas except 
that the user has the option to perform his 
own management of the entire area, thus 
allowing access to data arranged In non- 
standard formats. No disk pack verifica- 
tion Is performed for a Mount Area key-In 
(see "Unsolicited Key-Ins" in Chapter 3). 



These areas receive default allocations (see Table 27). 
Note that the SP and SD areas must be present In the 
system. 



SP 


UL 


SD 


BT 


SL 


CP 


UP 


Dn 


UD 


Xn 



where n is a hexadecimal digit, and Dn Is an area that may 
contain any data the user desires Including program files. 



PROCESSOR FILES 

Processor files are stored either as a single segment or as an 
overlay structure. The Overlay Loader stores the files on 
the RAD In core Image form, ready for loading, and abso- 
lutized for the space they will occupy at execution. The 
processor files are loaded for execution via a processor con- 
trol command. When allocating files, any file defined In 
an area with a P as the second character of the mnemonic 
is considered a processor file. 



RBM Characteristics 



LIBRARY FILES 



CHECKPOINT/RESTART 



Library files contain subprograms in a relocatable form. 
The files have specified entry points and are in the form of 
binary card images in Standard Object Language. 



There is one library file for the system area mnemonic SL, 
and one for the user area mnemonic UL. The Overlay 
Loader can load selectively from one or both, in either 
order of priority. Although records within a subprogram 
are loaded sequentially, access to the individual subprogram 
is on a random (direct access) basis. 



DATA FILES 

Permanent data files may contain any kind of data and may 
be accessed sequentially or randomly, depending on how 
they were created. The user is responsible for reading them 
accordingly. RBM maintains no details on content, address- 
ing, or record size. When allocating files, any file defined 
in an area with a D as the second character of the area 
mnemonic is considered a data file. 



FILE NAME 

Only permanent RAD files have a file name. Some names 
are entered into the dictionary for the appropriate area at 
System Generation; others are entered later by the RAD 
Editor. After the name Is in the dictionary, an [ASSIGN 
control command or a call to M:ASSIGN can equate either 
an operational label or a FORTRAN device unit number to 
this file name. 



The checkpointing feature permits a partially processed 
background job to be saved in secondary storage along with 
all registers and other environment. The vacated back- 
ground space is set to protected status and is then available 
to the interrupting foreground task for either instructions or 
temporary data storage. 

Checkpointing ensures continuity to the partially completed 
background job by not repositioning any background periph- 
eral devices, permitting all current background I/O activity 
to complete, and writing all of the background space onto a 
prespecified RAD area. 

Restart takes place when the previously checkpointed back- 
ground program is reloaded from the RAD and continues 
execution as though the interruption never took place. 



PUBLIC LIBRARY 

All RBM service routines and Sigma 2/3 system library rou- 
tines (FORTRAN and mathematics libraries) are reentrant. 
If an RBM system has several real-time foreground tasks that 
use a number of the same subroutines, the collectively-used 
set of subroutines can be loaded together into what is termed 
a Public Library. Thereafter, whenever the Overlay Loader 
processes a foreground or background program that references 
one of the "public" routines. It sets the appropriate branch 
to the Public Library. The Public Library is loaded into core 
whenever RBM is rebooted from the RAD. 

When one of the Public Library routines needs temporary 
scratch space, it requests space (via a call to M:RES) from 
the temporary stack of the task that is calling the Public 
Library routine. When the library routine exits, the space 
Is released via a call to M:POP. 



OVERLAY CAPABILITIES 

Under RBM, the Overlay Loader can be used to create over- 
lay programs for later execution in either the foreground or 
background.*^ The overlay programs can be permanently 
entered (as a file) Into either the System or User Processor 
areas, or Into a temporary overlay file (OV). Since they are 
stored on the RAD In absolute core Image format, they can 
be quickly loaded Into memory for execution. 



Each segment is created by the Overlay Loader from one or 
more object modules (assembly language, FORTRAN, or 
library routines). The control commands required to create 
the overlay segments are defined in the discussion of the 
Overlay Loader. During execution, the Monitor service 
routine M:SEGLD is used to control both the loading and 
the transfer of control between various segments. 



For a complete description of the Overlay Loader, see the 
Overlay Loader chapter. 



REENTRANT ROUTINES 

As used in Sigma 2/3 software, "reentrant" means that a 
subprogram (never a task) may be interrupted during execu- 
tion, called again by the interrupting task, and later re- 
entered and continued from the location of the former task. 
This is a last-in, first-out kind of reentrancy in keeping 
with the Sigma 2/3 priority interrupt system. 



ACCOUNTING AND ELAPSED TIME 

Background job accounting and provisions to limit the exe- 
cution time of a background job can be accomplished via 
Clock 1. (The use of Clock 1, an interrupt device, is 
optional at SYSGEN initiation.) To correctly calculate 
the elapsed time for the background, the Monitor M:SAVE 
routine records the start time of the first interrupting fore- 
ground task and triggers the RBM Control Task to calculate 
the actual foreground run time. By performing this calcu- 
lation at the priority level of the RBM Control Task, rapid 
response time for the foreground is maintained. 



RBM Characteristics 



Clock 1 Is also used to limit the execution time of a back- 
ground program. The user may limit this execution time by 
using the ! LIMIT control command, and the RBM Control 
Task will be triggered every 16 seconds to provide v/atchdog 
services on the background program. 

When a !JOB control command Is read, an entry is created 
in the accounting file (RBMAL, SD). The entry includes the 
start time, user name, and account number. The start time of 
the job is then logged on the LL device as MM/DD/YR HRMN. 

At the completion of each activity, the accumulated elapsed 
time since the start of the job will be logged on the LL 
device as ET=MMM.MM (minutes). At the completion of 
the job (I.e., a new IJOB or !FIN command) the current 
date and time and a job recap ore logged on the LL device as 



MM/DDAR HRMN 
FG=MMM.MM, 
where 



BK-MMM.MM, 
ID^MMM.MM 



BK represents the total job time. The total time 

for a job Is defined as the time available to the 
background from the time the ! JOB control com- 
mand is read until the next ! JOB or ! FIN command 
is encountered. 

FG represents the amount of time used by inter- 
rupting foreground tasks during the job. 

ID represents the accumulated idle time incurred 
within the job. Thiscouldbe a resu It of W key-ins 
or the result of an attended job being aborted. 



SYSTEM INITIALIZATION AND CREATION 

The RBM system creates Itself for a particular installation 
through a nonresident SYSGEN routine. The permanently 
resident, nonoptional ports of RBM are loaded into low core; 
next, the RBM Initializer Is loaded along with the optional 
RBM routines and the standard Input/output definitions 
and tables. 

The user then defines RAD areas, optional routines, the pe- 
ripheral devices, and operational labels. This Is followed 
by a definition of the exact bounds on the foreground. 
Monitor, and background memory areas, and the size of the 
RAD areas. The system Is then complete In lower memory. 

Once the system Is completely defined, routines not needed 
will be discarded and an absolute rebootable version is 
punched on a binary output device (optional) and a reboot- 
able version is written onto the RAD. The system initializer 
Is overwritten by the first background program or real-time 
foreground program loaded just below 12K. 

If the system must be restarted later, the rebootable version 
Is loaded from the RAD. A completely new system initiali- 
zation Is necessary only if some of these standard definitions 
must be changed. 

When the system is created, a version number is specified 
that will be printed on LL at the beginning of each job for 
reference. 

Protection switches on the 7202, 7204, and 7232 equipment 
may be used to permanently protect certain areas of the RAD. 



The time for a background job is recorded in the accounting 
file entry for that job. The IDLE account is updated to re- 
flect total idle time charges. After the IFIN control com- 
mand is read, all Idle time Is charged to the IDLE account. 

The following rules govern the operations of the Accounting 
Log: 

• A call to M:SAVE switches from the background to 
foreground time accumulation. 

• A call to M:EXIT switches from foreground accumula- 
tion to background accumulation if a background job 
is executing. 

• AW key-in switches from foreground accumulation to 
idle time accumulation. An abort from an attended 
job switches the same way. An S key-in switches 
back to foreground accumulation from the idle 
accumulation. 

• A IJOB or IFIN command writes out total accumulated 
times and resets times to zero. 

• The ET (elapsed time) represents the total background 
accumulation since !JOB was encountered. ET Is 
printed out each time CCI is read into the background. 



HARDWARE REQUIREMENTS 

The minimum configuration required and supported by RBM 
for either a Sigma 2 or Sigma 3 is the following: 

Sigma 2 or Sigma 3 CPU with either Internal lOP or 
External lOP (Sigma 3 only) 

Memory Parity Interrupt 

Memory Protect Feature 

Hardware Interrupt (for RBM Control Task) 

Core Memory Module (8192 words) 

One Memory Increment (8192 words) 

Keyboard/Printer with Paper Tope Reader/Punch 

RAD Controller 

RAD Storage Unit (0,75 M bytes) 



An alternate minimum configuration (for a Sigma 3 CPU with 
external lOP only) is a Disk Pack Controller and Disk Pack 
Storage Unit to replace the RAD Controller and RAD storage 
Unit. Other minimum requirements remain the same. 



Hardware Requirements 



In addition to the previous list, any items from the list 
below can be added for increased performance and will be 
specifically supported by RBM. Other items can be added 
to this list but will not receive any special RBM support. 

Disk Packs 

Memory Module 

Memory Increment 

Keyboard/Pri nter 

Paper Tape Reader/Punch (High-Speed) 

Card Readers 

Card Punches 

RADs 

9-Track Magnetic Tape 

7-Track Magnetic Tape 

BCD and Binary Packing Options for 7-Track Magnetic 
Tape 

Line Printers 

Plotters 



RBM SUBSYSTEMS 

RBM will support the subsystems and processors described 
below. All execute in the background area of core memory 
and the collective set offers maximized utilization of 
Sigma 2/3 computer capabilities. 



LANGUAGE TRANSLATORS 



EXTENDED SYMBOL 

The Extended Symbol programming language (and assembler) 
provides upward compatibility with basic Symbol in addi- 
tion to extended capabilities that include using the RAD 
for overlay to reduce core residence requirements. 

The processor accepts as input a source program coded in 
either Symbol or Extended Symbol, processes it, and out- 
puts an object program load module, diagnostic messages, 
an optional assembly listing, and an optional cross-reference 
listing. 



SERVICE PROGRAMS 

OVERLAY LOADER 

The Overlay Loader forms absolute binary overlay segments 
for later execution in either foreground or background areas. 
If a resident or nonresident program can tolerate a loading 
delay of 20 to 100 ms, foreground or background programs 
of virtually unlimited size can be constructed with the 
Overlay Loader despite limitations in available core storage. 

RAD EDITOR 

The RAD Editor performs RAD allocation for permanent files 
and generates and maintains directories for the permanent 
RAD areas: System Processor area. System Library area. 
System Data area. User Processor area. User Library area. 
User Data area, and any Dn areas and Xn areas. It allows 
dumping of files and mapping of all RAD areas, including 
checkpoint and temporary areas. 

UTILITY SUBSYSTEM 

The RBM Utility subsystem provides a universal media copy 
routine, object module editor, dump routine, and record 
editing by line or sequence number. 

CONCORDANCE 

The Concordance program provides the user with a listing 
of program symbols and all references to these symbols by 
source line number. Optional control cards permit Inclusjon 
or exclusion of specified symbols in local, nonlocal, or 
operation/directive code sections of the printout. Most of 
the options of Concordance are available under Extended 
Symbol. 

Omission of optional control cards yields a standard Con- 
cordance listing containing all program symbols except 
standard operation and directive code menmonics. 



MISCELLANEOUS 



DEBUG 



The RBM Debug subsystem provides the user with a debug- 
ging tool designed primarily for nonsegmented background 
programs but with a limited capability for debugging fore- 
ground programs. The Debug functions and commands are 
described in Chapter 12. 



BASIC FORTRAN IV 

Basic FORTRAN IV is a one-pass compiler with capabil- 
ities extended beyond Basic FORTRAN. It can compile 
large source programs by using the RAD for overlay to mini- 
mize core residence requirements, and has two floating- 
point modes: standard precision and extended precision. 



COC 

The character-oriented communications (COC) handler pro- 
vides communication between Sigma 2/3 real-time programs 
and various terminal devices. The COC consists of a con- 
troller and from one to eight attached line interface units. 
The Sigma 2/3 RBM can accommodate one COC. See Chap- 
ter 4 and Appendix F for a more complete discussion of the 
COC handler. 



RBM Subsystems 



RBM TERMS AND PROCESSES 

The following items are either unique to the RBM system or 
have specific meaning within the RBM context. Terms and 
processes not defined beloware explained in the appropriate 
chapter. 



TASK 

A "task" is an entire set of foreground operations performed 
independently of other tasks in the system. It must be con- 
nected to one and only one hardware interrupt. A task may 
use Monitor service routines but must never branch to another 
task. One task may trigger the interrupt level of another 
task by means of a Write Direct Instruction. The prescribed 
entrance and exit procedure for all real-time tasks in the 
system is described in Chapter 6. 

A task logically consists of three parts (that may or may not 
be contiguous in core storage): 

1. A Task Control Block (TCB) that contains status infor- 
mation and the contents of the registers from the inter- 
rupted task (see Table 27). The TCB is normally the 
first loadable item in the object module. 

2. A task body, consisting of a sequence of Instructions 
executed in response to the task interrupt. 

3. A task temporary storage area for use by the Monitor 
service routines (and other reentrant library routines) 
to provide reentrancy for these routines. 

Examples of foreground tasks are 

• Real-time foreground tasks connected to external 
interrupts. 

• Monitor I/O interrupt routine. 

• Monitor Control Panel interrupt routine. 

• Monitor memory parity and protection violation 
routines. 

• RBM control routine (for loading, abort, etc.) 

A background program can also operate as a single task but 
without foreground privileges. 

PROGRAM 

A "program" is one or more tasks (and optionally, some 
common data storage) that are loaded and controlled as a 
unit. Four types of programs exist under RBM: 

1. Resident foreground programs consisting of one or more 
tasks, perhaps some special routines for receiving I/O 
interrupt responses (see "End Action"), and any com- 
mon storage that may be needed. 



2. Semiresident foreground programs that are explicitly 
called in from secondary memory and reside In the 
resident portion of core memory during execution. 

3. Nonresident foreground programs. 

4. Background programs, consisting of a single task. 



FOREGROUND 

"Foreground" refers to real-time or Monitor tasks executed 
in protected memory on a real-time basis. Since the num- 
ber of foreground tasks Is limited only by the number of 
internal and external interrupts possible In the system, the 
fundamental limitation Is the amount of core space available. 
However, the use of overlays and nonresident foreground 
programs makes the amount of effective foreground space 
virtually unlimited, depending only on the severity level 
of required response times. 



BACKGROUND 

"Background" refers to a non-real-time program executed 
in available nonprotected memory. The purpose of back- 
ground programming is to achieve higher efficiency in the 
system by using up the available CPU time not needed by 
real-time tasks to maintain foreground programs, or to per- 
form other data processing functions. 



Background operations may be assemblies, compilations, 
data processing, or utility operations. The two fundamental 
restrictions in using background programming are 

1. Sigma 2/3 hardware and the RBM software completely 
and absolutely protect resident foreground programs 
from a background program in terms of I/O and core 
memory usage. Thus, a background program is never 
allowed to interfere with real-time foreground tasks: 
it must operate in nonprotected memory and use the 
Monitor service routines for all I/O or other privileged 
operations. 

2. Since a background program uses only the CPU time 
available after the real-time foreground is satisfied, it 
may not be guaranteed any CPU time when foreground 
is very active. The background is not allowed to in- 
hibit interrupts or do anything else that might interfere 
with real-time foreground responsiveness. 



JOB 

A "job" is defined as consisting of all background activities 
or processes that take place between a IJOB command and 
the next !JOB command or a IFIN command (whichever is 
encountered first). 



RBM Terms and Processes 



JOB STEP 

A "job step" is defined as the operations performed in setting 
up and processing a single program within a job stack. A 
job step is initiated by calling In a background processor 
and ends when the processor exits. 



BACKGROUND TASK 



As a convenience in referencing the floating accumulator, 
core locations 1 through 5 are set with pointers to the actual 
core locations. This is done when entry is made to the ac- 
tive task (by M:SAVEwhen the routine is used). Therefore, 
indirect addressing through locations 1 through 5 will result 
in storing, loading, or modifying the actual floating accu- 
mulator. The sixth cell of the floating accumulator is used 
by the FORTRAN-formatted I/O routine. 



A "background task" is an executable version of a single 
background process that shares the same restrictions as 
other background jobs relative to foreground priorities 
and privileges. 



MONITOR SERVICE ROUTINES 

RBM service routines can be used by real-time foreground 
tasks, a background task, or RBM tasks. All routines are 
coded in a reentrant manner, and those that require tempo- 
rary storage use the temporary stack space associated with 
the task that calls the routine (see Chapter 4). 



TEMPORARY STACK 

The temporary stack (temp stack) is a block of core storage 
associated with a particular task and is used by Monitor ser- 
vice routines for temporary storage to achieve reentrancy. 
An entry in the TCB for a task points to the temp stack 
space. When a task is active and using either Monitor ser- 
vice routines or the floating accumulator (defined below), 
the beginning of the temp stack space for the active task 
must be set Into core memory location 6 (after the previous 
contents of location 6 are saved). Monitor service routine 
M:SAVE will set this pointer. 

When Monitor service routines or Public Library routines 
need temporary space, they can call M:RES to reserve space, 
and M:POPmust then be called to release the space when it 
is no longer needed. Thus, the total temp stack is a func- 
tion of the deepest nesting of calls to Public Library routines 
and RBM service routines and of the space required for 
these routines. 



FLOATING ACCUMULATOR 

This software convention is used extensively by mathematics 
library routines and can also be used by any user's program. 
The floating-point accumulator Is assumed to occupy the 
first six locations of the temporary stack space. It is used 
like a hardware accumulator, I.e., to build up a cumula- 
tive result from single-precision or double-precision real 
(floating-point) calculations. 



RBM CONTROL TASK 

The RBM Control Task encompasses a number of subtasks 
that control the reading of control commands, loading back- 
ground programs, interpreting unsolicited key-Ins, and 
aborting or terminating a background job. During system 
initialization, the RBM Control Task must be assigned to the 
lowest priority hardware interrupt. 

The RBM Control Task uses the same entrance and exit pro- 
cedure and the same type of TCB as a real-time foreground 
task. Since its main function is to control background 
activity, it has a lower priority than any real-time task. 
It is necessary that this be a separate task (and not part of 
the background priority level) so that effective and respon- 
sive control can be made through key-Ins. All RBM func- 
tions associated with this level operate as subtasks to the 
RBM Control Task and are non-reentrant. 



NONRESIDENT FOREGROUND 

Nonresident foreground programs are real-time programs 
not needed In core on a continuous basis. They are created 
like resident foreground programs and are then written on 
the RAD In the user processor (UP) area. An operator or a 
resident real-time program can later call one of these non- 
resident programs, and it will be loaded and executed like 
a permanently resident real-time foreground program with 
all the protection and priority privilege characteristics of 
the foreground. 



COMPRESSED RAD FILES 

EBCDIC character codes do not use all possible bit combi- 
nations of an eight-bit byte, and some combinations (X'FC 
and X'EC) are therefore available for special coding bytes. 
Since EBCDIC information often contains a large number 
of "blank" byte strings, a code and a word count are used 
to replace an entire string of blanks. Thus, several 80-byte 
source cards (usually about 12) can be compressed and 
blocked into a 360-byte RAD sector. The RBM Read and 
Write routines provide the compression or decompression 
feature, and the user program can read or write as though 
the file contained 80-byte card images. 
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2. CONTROL COMMANDS 



The Monitor is controlled and directed by control commands 
that initiate loading and execution of programs and provide 
communication between a program and Its environment. 
The environment includes the Monitor, background proces- 
sors, the operator, and peripheral equipment. 

Control commands have the general form: 

/^ Imnemonic specification 



! Is the first character of the record and identifies 

the beginning of a control message. 

mnemonic is the mnemonic code name of a control 

function or the name of a processor. It must 
immediately follow the ! character without inter- 
vening spaces. 

specification is a listing of required or optional 

specifications. This may include labels and nu- 
meric values appropriate to the specific command. 
In the specification field, hexadecimal values 
must be shown as +xxxx and EBCDIC values must 
begin with a letter; any other values are assumed 
to be decimal values. Specification fields ore 
separated by a comma or an equals sign. 

In this manual the options that may be Included in the 
specification field of a given type of control command are 
shown enclosed In brackets although brackets are not used 
in actual control command format. 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field. 
A control command is terminated by the first blank after 
the specification field. Annotational comments detailing 
the specific purpose of a command record may be written 
following the specification terminator, but not beyond col- 
umn 72. Only columns 1-4 are examined to determine the 
control command. 

The user may insert comment lines within a job stack at any 
point where a Monitor control command would be recog- 
nized. A comment line contains an asterisk as the first 
character of the line. The comment line Is listed on the 
LL device. 

Communication between the operator and the Monitor 
Is accomplished via control commands, key-ins, and 
messages. Control commands are usually Input to the 
Monitor via punched cards; however, any input device(s) 
may be designated for this function (see ! ASSIGN com- 
mand). Control key-ins are always input through the 
keyboard/printer. All control commands and Monitor 
messages are listed on the output device designated as 



the listing log (normally a line printer) to provide a 
hard-copy history of a job. 

JOB CONTROL PROCESSOR [JCP) 

Monitor control commands are read from the background 
operational label CC unless the operator has requested a 
keyboard/printer override through an unsolicited KP key-in. 
All such commands are read by the Job Control Processor 
(JCP), a special processor loaded Into the background by the 
RBM and reloaded Into the background following each 
job step within a job. When a control command is en- 
countered by the JCP, the order of search is 

1. Monitor service commands. 

2. System processor names. 

3. User processor names. 



A UOB command sets all background operational labels to 
their standard assignments. All temporary RAD space is set 
"unused" and is then available for following job steps. I 

As the JCP encounters {ASSIGN and I DEFINE commands 
between job steps. It makes appropriate entries In the oper- | 
ational label tables and continues to do so until It encoun- 
ters a request for a processor. When the requested processor 
Is read Into the background and attains control, this marks 
the beginning of a job step. | 

At the end of each job step (I.e. , when the JCP begins 
reading control commands at the completion of the previous 
job step), all background operational labels associated 
with temporary RAD space are set to an undefined status 
and all temporary background space is reset to an "unused" 
status unless a ITEMP S control command Is in effect, which 
saves temporary files until a ITEMP R, UOB, or I FIN com- 
mand is encountered. 



MONITOR CONTROL COMMANDS 

ABS The !ABS control command causes the Absolute 

Loader to read absolute binary programs from the AI device 
and write core Image copies onto the OV file. The last 
(or only) segment to be read must be followed by an lEOD 
command. The binary program(s) following the lABS com- 
mand must contain only those load items that are part of the 
Sigma 2/3 Absolute Object Language. The program can be 
a background program, a processor for the background, or 
a real-time foreground program. 

A subsequent !XEQ command causes the RBMsubtask SrLOAD 
to load the core image of the root segment (segment number 0) 
from OV Into core storage. Subsequent segments (1 - n) 
are loaded by the root through the use of MrSEGLD. 
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When on !ABS control command is encountered, the 
Absolute Loader reads the absolute deck that follows from 
the AI device and writes the core image copy onto the file 
to which the OV operational label is currently assigned. 
If OV has not been assigned, it will be assigned by default 
to the RBMOV file on the RAD. The program can be exe- 
cuted from a permanent SP (system processor) or UP (user 
processor) file either by inputting a "Iname" command 
(where "name" is the name of the file on which the program 
was written), or an !XEQ command. 

If a multisegment program is loaded, the Absolute Loader 
creates an OVrLOAD table at the end of the root. The root 
must always be the first load module and each succeeding 
load module is assigned a consecutive segment identifica- 
tion number, with the first succeeding segment starting 
at "1". In the OVrLOAD table, each segment's load ad- 
dress will be at its origin location and its entry address will 
be the transfer address generated by the !END card image. 

The form of the !ABS control command is 

/'^^ABS [slzelCoplb^JCoplb^lC^opIb^]... Ooplb^^] 



labels for the background are reset to the standard values 
at the beginning of a job by the Job Control Processor, an 
operational label assignment is in effect only until the next 
!JOB command is encountered or until it Is again reassigned. 

An operational label is a two-character name that is used 
as a label in referring to a device-file number. The con- 
vention of operational labels is used for the processors or 
any other program to make them device-independent, and 
also to give some mnemonic value to the input/output opera- 
tions associated with the processors. 

Device file numbers are a logical means of referring both 
to a physical peripheral device and to a collection of in- 
formation about that device; that is, the current file of 
Information. Device file numbers are defined sequentially 
(and remained fixed) in the DEVICE FILE INFO parameter 
during SYSGEN (see Table 27). 

Standard operational labels can be reassigned to different 
device-file numbers during SYSGEN or through lASSIGN 
and {DEFINE control commands. One table of operational 
labels is used for the background (see Table 2 below) and 
another table is used for the foreground. Device unit 
numbers are also stored in the same two tables as binary 
integer values. 



size Is an optional parameter for background pro- 

grams only. It specifies the temp stack size 
required for the background program being 
loaded. If size is omitted, a temp stack size 
equal to the maximum size needed for all Monitor 
service routines (80) will be used. The temp stack 
will always be allocated at the start of back- 
ground, and it is the user's responsibility to origin 
his program above the temp stack. For foreground 
programs, the size parameter Is ignored and the 
temp stack pointers must be assembled as part of 
the program (i.e., in the TCB). 



Table 2. Standard Background Operational Labels 



oplb] ,oplb2 



are operational labels used by the 



program that require blocking buffers (i.e., those 
labels that may be assigned to blocked RAD files). 
A maximum of 10 operational labels may be speci- 
fied. When the program Is loaded from the RAD 
for execution, the Monitor will ensure that enough 
block buffers are available for these specified 
labels assigned to blocked files. 

Programs loaded under the Absolute Loader are subject to 
the following restrictions: 

• No external references are permitted. 

• The program must be in absolute form. 

• Relocatable code may not be Imbedded. 



ASSIGN The lASSIGN control command causes either a 

new or standard operational label to be equated with a 
specified (or temporary) file number. Since operational 



Operational 
Label 


Explanation 
of Reference 


I/O Device 


AI 


ABS binary input 


CR,PT,MT,RD 


BI 


Binary Input 


CR,PT,MT,RD 


BO 


Binary output 


CP,PT,MT,RD 


CC 


Control command 
input 


KP,CR,PT,MT, 
RD 


DO 


Diagnostic output 


Same as LO 


GO^ 


Execution input (GO) 


CR,MT,PT,RD 


ID 


Debug ident file 


RD 


LI 


Library Input 


Same as BI 


LL 


Listing log 


Same as LO 


LO 


Listing output 


LP,KP,MT,RD 


OC 


Operator's console 


KP 


OV^ 


Overlay (temporary) 


RD 


pi" 


Processor Input 


RD 


PM 


Punch RBM 


CP,PT,MT 
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Table 2. Standard Background Operational 
Labels (cont.) 



Operational 
Label 


Explanation 
of Reference 


I/O Device 


SI 


Symbolic input 


KP,CR,PT,MT, 
RAD 


S2^ 


Sigma 2/3 procedures 


RD 


UI 


Update input 


CR,PT,MT,RD 


UO 


Update output 


PT,MT,RD 


Xl^^^ 


Extended Symbol 


MT,CR,RD 


X2^^^ 


Overlay Loader, 
Extended Symbol 


RD 


X3^^^ 


Extended Symbol 


RD 


xr 


Utility (verify) 


RD 


X5"^ 


Utility (prestore) 


RD 


These operational labels, if required by a processor, 
are automatically assigned to permanent files in the 
system data area by the Job Control Processor. 


The PI operational label is assigned to files in the 
System Processor and User Processor areas by the Job 
Control Processor. 


These operational labels are automatically assigned 
to background temporary RAD files, with the file defi- 
nition appropriate to the background processor being 
executed. These definitions are made from a table in 
the Job Control Processor that is selected by the first 


three characters of the processor name. 



{ASSIGN commands can appear anywhere within the con- 
trol command stack (except within a job step) and take 
effect immediately. That Is, If the CC operational label is 
reassigned, the very next control command is read from the 
newly ossigned device (unless the KP override has been 
imposed by an unsolicited key-in). The lASSIGN com- 
mand Is used for both foreground or background operational 
labels. (The operator must key In FG before assigning a 
foreground operational label.) 



There are three forms of the lASSIGN command. Form 1 Is 



(ASSIGN opib =file number[,F] 



opib is either a two-character alphanumeric name 

in the foreground or background operational label 
table (or is to be placed In the table), or a 
FORTRAN device unit number. Indicated by the 
prefix F: preceding the device unit number (see 
Table 3). 

file number Is the device-file number for a physical 
device in the system (created at SYSGEN). 

F when present, declares that the assignment Is to 

be included in the foreground operational label 
table. Otherwise, it is assumed to be in the back- 
ground operational label table, and the file num- 
ber must also be a background file number. 



Form 2 of the lASSIGN command is 
/ lASSIGN opib =file name ,area mnemonic [/Fj 



The standard foreground operational labels are as 
follows: 



Operational Explanation of 

Label Reference 



BO 
AL 



Binary output 
Accounting log 



I/O Device 

CP,PT,MT 

RD 



An assignment to file zero means that the operational label 
is not effective, and all references to this operational label 
result in a no-operation until it Is reassigned. Note: some 
background processors (e.g.. Utility) do not allow use of 
active operational labels assigned to file zero. See 
Appendix E for a complete description of operational label 
usage. 



opib is an operational label or a device unit num- 

ber identified by the F: prefix. 

file name is the name of an existing RAD file. The 

RAD file is rewound if it is blocked or compressed. 
Only permanent RAD files can have a file name. 
Once the file name Is entered in the dictionary 
by SYSGEN or RAD Editor, an lASSIGN control 
command or call to M:ASSIGN can equate either 
an operational label or FORTRAN device unit 
number to this file name. 

area mnemonic specifies the area to search for the 
filename, usually from the areas listed in Table 4. 

F Indicates that the assignment is to be included 

in the foreground operational label table. 
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Table 3. Standard Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Card reader 


106 


Card punch 


108 


Line printer 



Table 4. RAD Area Mnemonics 



Code 


Meaning 


SP 


System Processor area 


SD 


System Data area 


SL,UL 


System and User Libraries 


UP 


User Processor area (user tasks and 




programs and background processors) 


BT 


Background Temp area 


CP 


Checkpoint area 


Dn 


Data area(s) 


UD 


User Data area 


Xn 


Similar to Dn areas but no disk pack 




verification performed 



Form 3 of the [ASSIGN command is 



/lASSIGN opib =oplb [, f] 

where 

opIb is as defined above. 

F if present, indicates that both operational labels 

are foreground; otherwise, both operational labels 
must be background labels. 



Examples: 



Form 1; 



Form 2: 



Form 3: 



[ASSIGN SI =3 
[ASSIGN F:105 =3 
[ASSIGN OV=FILEl, UP 

[ASSIGN LI = BI 



ATTEND The [ATTEND control command indicates that 

RBM is to go into a wait condition on any abort from the 
background, and then read and process the next control com- 
mand encountered when background processing continues 
after an unsolicited key-in. Its primary purpose is to offer 
improved recovery point procedures. If an abort occurs 
without this control command being specified, JCP will re- 
set the CC operational label to the standard value, skip all 
control commands, binary records, or data until it finds a 
new [JOB or [FIN command, and will not pause for opera- 
tor intervention. In this "skip" mode, all EBCDIC records 
beginning with I will be listed on the LL device, with an 
indication ('>' preceding the command) that they are ig- 
nored. This is the normal mode for closed-shop batch pro- 
cessing, without halts between jobs after aborts. 

The form of the command is 
/[ATTEND 



It exists for one job only, and usually immediately follows 
the [JOB command. 



C: The [C: control command connects the designated 

real-time foreground task to a specified interrupt location, 
optionally armed and enabled as specified by the control 
code. The task may also be triggered by means of this con- 
nect operation if the code is equal to seven, providing that 
the task has previously been armed (i.e. , with a previous 
IC: command, an [XEQ or "[name" command, or by a 
Q key-in). 

The form of the [C: control command is 



TCB [,code] 



wh( 



TCB is the address of the Task Control Block for 
this task. If the value is hexadecimal, it must be 
shown as -bcxxx. If the Overlay Loader initializes 
the TCB by means of the TCB parameters, it does 
so completely, using load information and values 
on the TCB and BLOCK cards. No partial initiali- 
zation of a TCB is allowed with the exception of 
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the blocking buffer pool. If a user buflds his own 
TCB, the TCB must begin at the execution location 
plus the "temp" value specified on the Overlay 
Loader !$ROOT command. 

code when present. Is the Interrupt operation code. 
It overrides the initial TCB task code; a code of 
7 triggers the task if it is armed. 

Note; If "code" is not specified, the code given 
in the TCB will be used. 

The IC: command does not change the contents of the TCB. 



CC The !CC control command returns control to the cur- 

rently assigned CC device and nullifies the effect of a 
previous KP key-In. The control command Is honored 
regardless of whether or not the "skip" mode is In effect. 
The "skip" mode is cleared following this command. The 
form of the command Is 



ICC 



DEFINE The IDEFINE control command allocates a 

portion of the background temporary RAD space for a spe- 
cific operational label or device unit number by assigning 
the operational label to an unused device-file number, 
which in turn Is linked to the specified portion of the RAD. 
Since temporary RAD files are not maintained by the Moni- 
tor, they have no name and are Identifiable only by the 
operational label for which each file was created. The 
IDEFINE control command must precede the specific pro- 
cessor or user program to which it applies, since this tem- 
porary space Is reset at the beginning of each fob and at 
the subsequent reloading of the JCP (unless a ITEMP S 
control command is in effect). That Is, the files are de- 
stroyed and the RAD space and all device-file numbers 
linked to It may be used by the next fob. 

The form of the IDEFINE control command is 



IDEFINE opib, nrec,srec 



f R 
C 



opIb is an operational label or a FORTRAN device 

unit number (with a prefix of F:). 

nrec is the number of logical records in the file. 

srec is the logical record size. In bytes. 

R defines the file as a random-access file. 



U defines the file as an unblocked file. 

C defines the file as a compressed EBCDIC file. 



If neither R, U, nor C is specified, the file Is defined as a 
subsequentlal, noncompressed, blocked file. If R Is Input, 
srec Is used as the granule size. 



EOD Blocks may be defined in a user's deck by Inserting 

JEOD control commands at the end of each block. When an 
!EOD command Is encountered, the Monitor returns an EOD 
status (when using the MrREAD I/O routine). This Is similar 
to a tape-mark on magnetic tape. Any number of lEOD con- 
trol commands may be used In a fob wherever desired by 
the user. 

The form of the ! EOD control command is 

lEOD 



FIN The I FIN control command specifies the end of a 

stack of fobs. When the ! FIN control command Is encoun- 
tered, the Monitor writes It on the listing log to inform the 
operator that all current fobs have been completed and also 
writes ! ! BEGIN IDLE on the OC device. The Monitor then 
enters the Idle state. 

The form of the I FIN control command is 



IFIN 



FSKIP,FBACK,RSKIP,RBACK The file positioning con- 

trol commands, IFSKIPand IFBACK, forward or backspace 
the specified device (magnetic tape or sequential RAD file) 
immediately past the next file mark, or past the nth file 
mark If n files are specified (n = 1 for RAD files). IRSKIP 
and jRBACK perform similar functions but act on records 
rather than files. IRBACK does not apply to compressed 
RAD files. 

The forms of the control command are 



IFSKIP 1 
IFBACK 
IRSKIP 
IRBACK 



device [, number] 



device is the device indicator of the device to be 

positioned and is restricted to background devices. 
The device Indicator is one of the following: 

1. A device-file number, shown as a decimal 
integer. 
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2. A FORTRAN device unit number, shown as 

F:n 

where n Is a decimal Integer equal to the de- 
vice unit number. 

3. An operational label, shown as two alpha- 
numeric bytes, the first of which is alphabetic. 

number Is the number of operations to be performed; 
If absent, one operation Is assumed. 



HEX The ! HEX control command loads patches at execu- 

tion time for either the Monitor Itself or any user program. 
(See Appendix G for input description.) 



The form of the !HEX control command is 



!HEX 



JOB The !JOB control command signals the beginning 

of a new fob. The background operational labels and 
FORTRAN device unit numbers are set to their standard 
assignments as defined at System Generation. All RAD 
temp files are closed. 



This command always causes a page to be ejected on the 
LL device before the command Is listed. The version of 
the RBM being utilized will be Inserted following the last 
field on the !JOB command. 



The form of the !JOB control command is 
/ .'JOB [name, account] 



name has a limit of 12 characters, 

account has a limit of six characters. 



JOBC The IJOBC control command indicates a con- 

tinuation of the current job. UOBC closes all RAD temp 
files and resets all background operational labels to their 
standard assignments (with the exception of "CC")- The 
IJOBC command does not clear the "attend" flag or the 
"skip" mode, nor does It terminate the effect of an FG or 
SY key-in. (A useful application of the IJOBC command 
is given in the Utility job deck example in Chapter 10.) 



The form of the ! JOBC control command Is 
/IJOBC 



LIMIT The I LIMIT control command Is used to set a 

maximum on the execution time of a background program. 
This command is effective only if the system has real-time 
Clock 1 dedicated to the Monitor. If the job exceeds the 
time limit, the Job is aborted (TL) and is terminated with a 
postmortem dump (If that option was specified). 

The form of the I LIMIT control command is 



/ 



LIMIT [n] 



where N is the maximum allowable execution time in min- 
utes (0 < N < 6000). 

MESSAGE The {MESSAGE control command Is used to 

type a message to the operator. It Is useful for messages 
concerning mounting tapes or setting certain device or 
Control Panel conditions. The command is listed on the 
OC device. There is no response. 

The form of the ! MESSAGE control command is 

A 



[MESSAGE message 



where message Is any comment to the operator, up to the 
full-card Image size (total of 72 columns per card). 



PAUSE The I PAUSE control command temporarily sus- 

pends background operation to allow the operator time to 
complete the job setup. Background operations resume when 
the operator performs an unsolicited S key-in. The command 
Is listed on the OC device. 

The form of the ! PAUSE control command Is 

! PAUSE message 



where message is a comment to the operator, up to the full- 
card Image (total of 72 columns per card). 



PMD The !PMD (postmortem dump) command causes the 

Monitor to dump the registers plus selected areas of mem- 
ory if an error occurs during program execution. The dumps 
are always onto the background DO device in hexadecimal 
format. 
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The form of the ! PMD command Is 

/\ PMD [U] L all] [ , from, to] . . . [from, to] 



where 



U if present, signifies an unconditional dump at 

the end of the next job step even if there are 
no errors. 

ALL if present, signifies that all of the background 

memory is to be dumped. If ALL is not present 
and no limits are specified, only the general 
registers are dumped. 

from specifies the location (decimal or hexa- 

decimal) at which dumping is to begin. 

to specifies the last location to be dumped. 



Up to four limit-pairs may be specified. The CPU registers 
are printed in hexadecimal as the first line of the dump 
regardless of the limits. 



PURGE The ! PURGE control command is used to output 

the contents of the accounting file. The output Is to back- 
ground operational label LO in the following format: 

mm/ddAy hrmn name account time 

(MMMM.MM) 

An option Is provided to clear the accounting file sub- 
sequent to this output. In this manner the user could assign 
background operational label LO to a device such as the 
card punch or the paper tape punch, and by exercising the 
"clear" option, could produce a periodic hard copy of 
the accounting file and clear the accounting file for 
future use. 

The form of the ! PURGE control command is 



! PURGE [C] 



where C is the directive to clear the accounting file (must 
be preceded by an unsolicited SY key-in). 



REL Relocatable binary program modules to be loaded 

onto the GO file are preceded by an !REL control com- 
mand. The binary modules that follow must be In Sigma 2/3 



Standard Object Language. The modules may constitute 
a complete program, a root, or segments of a program. 



The form of the !REL control command is 

A 



!REL 



The modules are copied onto the file to which GO Is cur- 
rently assigned. If GO has not been assigned. It will be 
assigned by default to the RBMGO file on the RAD, which 
is rewound before the modules are copied. Several modules 
may be copied through the use of one I REL control command 
by stacking the modules. The final module must be fol- 
lowed by an lEOD control command that will cause the 
JCP to write an end-of-file (EOF) onto GO and then 
backspace one file. In this manner the GO file is 
positioned to accept additional Input, but Is always 
terminated by an EOF. The relocatable binary decks are 
loaded from operational label BI. 



The I REL control command is a convenient method of 
obtaining additional hard copies of obfect modules pro- 
duced on GO by Extended Symbol or FORTRAN. By as- 
signing BI to GO and then reassigning GO to BO, modules 
will be copied from the original GO onto BO up to and 
Including the EOF. BI should be rewound before each 
I REL command. 



REWIND The ! REWIND control command rewinds a mag- 

netic tape or a sequential RAD file and has no effect on 
other devices. The operation takes place Immediately 
after the command is interpreted. The command is re- 
stricted to background files. 



The form of the ! REWIND control command is 

A 



[REWIND device 



where device is the device Indicator (as in IFSKIP) of the 
device to be rewound. 



TEMP Normally, the temporary background space on 

the RAD Is reset at the completion of each step within a 
job, so that a separate assembly and compilation can each 
have full access to this temporary area for scratch space 
as needed. The ITEMP control command Is a means of 
altering this standard procedure. When used with the 
save (S) option, temporary files are not released after any 
job step within a job stack until either a ITEMP command 
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is encountered with a reset (R) option or the next ! JOB, 
!JOBC, or !FIN command is encountered. 



The form of the !TEMP control command is 



ITEMP 



a 



where either S or R is required 

S means to save RAD temporary files between job 
steps within a job (e.g. , between an assembly 
and a concordance). 

R means to reset the RAD temp files after each job 

step. 



UNLOAD The lUNLOAD control command causes a 

specified magnetic tape or sequential RAD file to be re- 
wound in manual mode. Operator intervention is required 
to use the device again. If the device is a sequential RAD 
file, the file is rewound to BOT and released by a call to 
MrCLOSE. The command is restricted to background files. 

The form of the I UN LOAD control command is 

lUNLOAD device 



where device is the device indicator (as in IFSKIP) of 
the file to be rewound off-line. 



WEOF The !WEOF command writes the appropriate end- 

of-file mark on the output device. The command is 
restricted to background files. For magnetic tape, it 
is a tape mark; for the card punch or paper tape punch, 
it is an !EOD command; and for sequential RAD files, 
it is a logical file mark. 

The form of the IWEOF control command is 

A 



IWEOF device [, number] 



device is the device Indicator (as in IFSKIP) 

of the device that is to have an end-of-file writ- 
ten on it. 

number is the number of end-of-files to be written. 

If absent, one end-of-file is written. 



XEQ The !XEQ control command loads the first program 

from whatever file the OV operational lobe! is currently 
assigned to. For foreground programs, the command must 
be preceded by an FG key-in. 

The form of the !XEQ command is 



!XEQ 



XED The !XED control command performs the same oper- 

ations as the !XEQ control command except that I XED 
transfers control to RBM Debug through the entry point 
D:KEY when the root segment has been loaded. The mes- 
sage ! !D KEY-IN will appear on the keyboard/printer and 
the user can then input Debug control commands. (See 
Chapter 12 for a discussion of RBM Debug.) The !XED 
control command causes the background operational label 
ID to be default-assigned to the RBMID file on the RAD if 
it is not already assigned. 



The form of the !XED control command is 
/ !XED 



PROCESSOR CONTROL COMMANDS 

System processors on the System Processor area and any user 
background or foreground program residing in the User 
Processor area can be called by a processor control com- 
mand. The commands have the format 

! processor parameters 



processor is the file name of a processor (see 

Table 5). 

parameters are optional parameters interrupted by 

each particular processor. 



When a processor control command is read and interpreted 
by the Job Control Processor, the root segment of the speci- 
fied subsystem is loaded from the RAD into memory. The 
JCP will assign all permanent RAD files used by the speci- 
fied processor before the processor Is executed unless these 
files were previously assigned via lASSIGN commands. The 
JCP will also define all temporary operational labels used 
by the processor (by defining them as background temp 
files) unless they are previously defined via ! DEFINE com- 
mands. JCP then transfers control to the processor. 
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Table 5. RBM System Processors 



Name'' 


Description 


! FORTRAN 
ICONCORDA 

lOLOAD 
! UTILITY 
IXSYMBOL 
IRADEDIT 


Basic FORTRAN IV Compiler 

Concordance Program for 
Extended Assembler 

Overlay Loader 

Utility 

Extended Symbol Assembler 

RAD Editor 


The RBM System Processor names are entered into 
the System Processor area dictionary with the RAD 
Editor I'^^ADD command. If the file name is less 
than eight characters, the name on the processor 
control command must exactly match the file name. 
If the file name is eight characters (maximum), the 
first eight characters of the name on the processor 
control command must exactly match the file name. 
Trailing nonblank characters beyond the eighth 
character in the processor control command name 
are ignored. 



When a requested processor Is read into the background 
and attains control, this marks the beinning of job step. 
An example of a job stack illustrating its breakdown by job 
step Is shown In Figure 2. 



EXTENDED SYMBOL CONTROL COMMAND FORMAT 

The Job Control Processor reads and interprets the 
IXSYMBOL control command and loads the Extended Sym- 
bol assembler from the RAD Into background memory. The 
assembler continues to assemble programs until It encounters 
an end-of-file. The Extended Symbol assembler is called 
into operation with the command 

IXSYMBOL [option. , option-, ... ,optIon J 



where option can be 

BA specifies batch assembly mode. 

BO specifies binary output. 

CR specifies cross-reference listing. 



Job Step 




IFIN 



lEOD 



l*REWIND UI 



l*COPY F, ALL, FORM 



!*OPLBS LO 



I UTILITY COPY 



I ASSIGN LO=2 



I ASSIGN UI=10 



[REWIND LO 



Job Step 




lEOD 



Source Deck 



IXSYMBOL LO,CR 



IREWIND 10 



I ASSIGN LO=10 



[ATTEND 



IJOB 





Monitor enters 
"Idle" state. 



JCP is read into 
background 



Utility is read 
into background. 



JCP Is read Into 
background. 



Extended Symbol 
Is read into 
background. 



Figure 2. Job Stack Example 
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DW specifies display warnings. 

GO specifies output GO file. 

LO specifies list assembly output. 

NP specifies no standard procedure input. 

NS specifies no summaries. 

PP specifies punch standard procedure file. 

SL specifies simple literals. 



Any number of options may be specified and in any order. 
If no options are specified, the following options are 
assumed by default: 



BO, GO, LO 



The presence of any nondefault option requires that any 
desired default options (except SI which is always defaulted) 
must also be present. 



BASIC FORTRAN IV CONTROL COMMAND FORMAT 

The Job Control Processor reads and interprets the {FORTRAN 
control command and loads the Basic FORTRAN IV compiler 
from the RAD into background memory. The compiler is 
called into operation with the command 



I FORTRAN [S.,S_,...,S ] 



r-'2' 



where S, can be 

LO specifies an object listing. 

LL specifies an object listing with data chains. 

XP specifies extended precision real data instead 

of standard precision. 

ALL specifies that multiple files are compiled. 

FORTRAN will ignore single end-of-files and 
will terminate compilation only when two con- 
secutive end-of-files are read. 



Binary output is normally output on both the BO and GO 
devices. To suppress the BO or GO output, the user must 
assign the pertinent device to (see {ASSIGN and {DEFINE 
control commands in this chapter). 

If no specifications are present, binary output on the BO 
and GO devices, a source listing, and standard precision 
mode are assumed by default. 



RBM/PROCESSOR INTERFACE 

Ground rules common to all system processors are: 

• All processors operate in the background. 

• With the exception of the UTILITY program, processors 
must use standard background operational label table 
assignments for their I/O requests. (See Table 2 for 
the standard background operational labels.) 

• The first character of each line of the listed output 
from the processors is always interpreted as a vertical 
format character (carriage control) and is never printed. 
The RBM I/O routines treat the vertical format properly 
for the keyboard/printer, line printer, and magnetic 
tape. 

• When the RBM transfers control to a background pro- 
cessor, the X register contains the address of the con- 
trol card image, providing access to any parameters. 

• At the completion of an assembly or compilation, the 
processor writes two end-of-files on the LO device, 
and then backspaces the LO device one file. The 
MrCTRL routine will treat these operations for the 
devices as described in the I/O section. This permits 
file processing of output on magnetic tape, if LO is 
assigned to magnetic tape. The processor writes an 
EOF on BO and GO at completion and then back- 
spaces one file (GO and BO are separate options). 

• The processor generally returns control to RBM by 
means of a call to M:TERM. RBM will immediately 
read from CC and if there is another control command 
for the current processor, it will reload the processor 
from the RAD. 

• If overlay loading is required, the processor uses 
M:SEGLD. The overlay operational label for the 
background is PI. 

• If an unrecoverable error occurs, the processor exits 
to RBM with a call to M:ABORT and displays the abort 
code in the X register and the abort location in the 
A register. 

• Since all standard RAD files are defined by the Job 
Control Processor, the processors need not call 
M;DEFINE, but must call M;CLOSE to release blocking 
buffers in those cases where several RAD files are used 
but are not all open at one time. 

• The first ouput line to LO from an assembly or com- 
pilation causes a page eject. 



GO AND OV FILES 

Figure 3 shows how the JCP and Extended Symbol or Basic 
FORTRAN IV use the operational labels GO and OV. The 
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0. 



Relocatable binary decks 
copied directly from BI to 
GOby JCP with anlREL 
control command. 












w 








Assembler or compiler out- 
put to both GO and BO. 











Overlay Loader takes 
input from GO to form 
executable OV. 



JCP forms executable pro- 
gram directly from AI to 
OV with an !ABS control 
command. 





Executable program; called 
by !XEQ command; loaded 
by RBM subtask S:LOAD. 



Figure 3. Use of GO and OV Files 



GO and OV files are the files to which these operational 
labels are assigned by the JCP and are standard default 
files when no operational labels are specified. The GO 
file is a blocked, sequential file that contains relocat- 
able binary decks read from the }ob stack, and binary 
ouput produced as a result of an assembly or compila- 
tion. After each module is loaded onto the file, an 
end-of-file mark is written and a backspace file is per- 
formed- Thus, at any point within a job stack the 



GO file contains all modules that have been loaded and is 
in position to accept others. 

The Overlay Loader may now use the contents of the GO 
file to create an executable core image program and save 
this program on the random-access OV file. Absolute bin- 
ary decks produced by an assembly may also be written (in 
executable core Image form) onto the OV file by JCP 
through use of the !ABS command. 
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3. OPERATOR COMMUNICATION 



SYSTEM COMMUNICATION 

When events take place In the system that require operator 
intervention, or when one job is completed and another job 
begins, RBM informs the operator of these conditions by 
messages on the keyboard/printer. All such messages from 
the Monitor begin with two exclamation marks (!!). 



automatic to manual and back to automatic, depending on 
the initial condition.) When the change of state is sensed, 
the operation is retried. Thus, if the device is EMPTY, it 
need only be placed in the automatic mode. If there is a 
PUNCHES error or a FAULT on the card reader, the reader 
is unloaded, the bad cord is corrected and replaced, and 
the reader is returned to the automatic mode. 



Generally, these messages require no operator response on 
the keyboard/printer but may indicate that some peripheral 
device needs attention. In some cases, the operator must 
interrupt and key in a response after correcting the speci- 
fied problem. 



I/O RECOVERY PROCEDURE 

If a message concerns an I/O error condition, the Monitor 
I/O routines that generated the message will be waiting to 
sense a change of state in the device. (A change of state 
is defined as a change from manual to automatic, or from 



MONITOR MESSAGES 

The messages Itemized in Table 6 are output on the OC de- 
vice. They are primarily for background program use but 
can be used by foreground by specifying standard error re- 
covery and "Initiate and wait" In the M:READ, M:WRITE, 
or MrCTRL calling sequence. 



Real-time programs with special requirements can Inform 
the operator of special conditions and wait for an oper- 
ator response. 



Table 6. Monitor Messages 



Message 


Meaning 


! ! ABORT CODE xx LOC yyyy 


The background job has aborted by reason of code xx (abort codes 
are defined In Appendix C). If this was a CC abort (control com- 
mand error), a more explicit reason will be listed on the background 
DO device. (All abort messages and diagnostics are listed on the 
DO device.) If the system is operating In an "attend" mode (see 
Chapter 2), RBM will perform any required postmortem dumps and 
then go into a waitstate after an abort. After a subsequent S key-in, 
RBM will recover and attempt to process the next control com- 
mand on the CC device. If not operating In the "attend" mode, 
RBM will not go Into a wait state but will perform any required post- 
mortem dumps and Immediately begin reading from the standard 
CC device, skipping all control commands or data cards until a 
UOB or !FIN card is found. All control commands ore listed on 
the LL device, with an indication — a '<' preceding the command 
to show that they are being ignored. 


!!AL lOERROR^ 
! ! BEGIN WAIT 


An irrecoverable I/O error has occurred while accessing the ac- 
counting file, normally because of a hardware failure or unavaila- 
bility of operational label AL. The correct assignment of this 
operational label is to RBMAL,SD. An attempt should be made to 
recover the contents of the accounting file as stated above. If 
this recovery falls, the operator may gain control through a KP 
key-in and then on FG key-In to allow foreground modifications; 
the foreground operational label AL may then be reassigned (e. g. , 
"ASSIGN AL = RBMAL,SD,F or ! ASSIGN AL = 0,F). 

Note: Assignment of the foreground operational label AL to zero 
will Inhibit the logging of job stack entries into the 
accounting file. 


This alarm occurs only if the RBM accounting option has been exercised at SYSGEN. 
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Table 6. Monitor Messages (cont.) 



Message 


Meaning 


!!AL OVERFLOW^ 
!! BEGIN WAIT 


The accounting file (RBMAL) cannot accept another entry. The 
accounting file is allocated at SYSGEN and accommodates 
74 entries. (The user may increase or decrease this capacity via 
the RAD Editor.) At this point, normal error recovery will be a 
key-in of KP to gain keyboard/printer control. Next, a key-in 
of SY will permit access to the accounting file. The operator 
should now assign the background operational label LO to a hard- 
copy device (e.g., paper tape, card punch). Input of a 1 PURGE 
control command specifying the clear option (i. e. , ! PURGE C) 
causes the contents of the accounting file to be copied onto that 
device and clears the accounting file. The job stack causing the 
overflow can now be reentered. 


!! ATTEND ERRORxx 


JCP has read an erroneous control command while operating in the 
ATTEND mode, in which case RBM goes into a WAIT state after 
typing this message. After a subsequent S key-in, RBM will process 
the next control command. 


!! BEGIN IDLE 


JCP has just read a !FIN card (which completes a job stack) and 
background has gone into an Idle state. Processing will resume on 
a new job stack following an unsolicited S key-In. 


!! BEGIN WAIT 


The background has executed a WAIT request. An unsolicited 
S key-in will continue background processing. 


MBKGCKPT 


Background has been checkpointed as a result of a foreground pro- 
gram request. 


!!BK RELEASE^dtnn 


The specified device has been released for background use. 


IIBKG RESTART 


Background has been restarted from Its point of interruption. 


!!CCI 


JCP has begun to read control commands. This message occurs at 
the beginning of a job and between steps within a job (e.g., 
when an assembly is completed). If CC is assigned to the keyboard/ 
printer (as a standard assignment, or after a KP key-in), the input 
light on the keyboard/printer will indicate that RBM is ready for 
input of a control command. 


!!dtnn EMPTY 


The device specified is in the manual mode and may be out of 
paper, cards, or tape. 


!!dtnn ERROR [,TRK xxxx] 


There has been a parity or transmission error on the device. If any 
automatic retries were specified, they will have been performed 
before this message Is output. A CR device will Indicate that an 
error card is In the output stacker. Recovery procedure is described 
above under "I/O Recovery Procedure". If it Is RD, xxxx will be 
the errored track number. 


This alarm occurs only if the RBM accounting option has been exercised at SYSGEN. 
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Table 6. Monitor Messages (cont.) 



Message 


Meaning 


Hdtnn FAULT 


Some condition on device type dt with physical device number nn 
(hexadecimal) has caused this device to become nonoperational. 
The recovery procedure is described above (in the discussion under 
change of state). The operation is automatically retried when the 
device goes into the automatic mode; it is neither necessary nor 
possible for the operator to type in a response. 


!!dtnn PUNCHES 


An invalid punch combination has been sensed on an EBCDIC 
image. 


!!dtnn RATE ERR 


A data rate overrun has occurred. If any automatic retries were 
specified, they will be performed after this message is output. 


!!dtnnUNRECOG 


Device type dt with device number nn (hexadecimal) is not recog- 
nized by the I/O routines. If the device is a magnetic tape unit, 
the requested drive may not be dialed in properly or power may be 
off in either the unit or the controller. 


NdtnnWRTPROT 


Either the RAD is physically write-protected or a RAD file is logi- 
cally write-protected. If a RAD file is logically write-protected, 
an unsolicited key-in of SY will allow RBM to continue. If the 
background is attempting an invalid operation, it should be 
aborted. 


!!END IDLE 


RBM has gone out of the idle state and will begin reading control 
commands from the CC device. Control commands will be ignored 
until a ! JOB command is input. 


!!FG PARITY ERR, TCB=FFFF, LOC=FFFF, 
A=FFFF, X=FFFF, B=FFFF 


A foreground parity has occurred but the specified allowable limit 
of foreground parity errors has not been reached. 


!!FG PARITY ERX, TCB=FFFF, LOC=FFFF, 
A=FFFF, X=FFFF, B=FFFF 


A foreground parity error has occurred. The specified allowable 
limit of foreground parity error has been reached. ERX indicates 
that the task has been disabled and terminated. 


!!FG REQUEST,dtnn 


A request has been made to reserve the specified device. The 
operator should prepare the device and then reserve it through use 
of the FR key-in. 


!!FG RESERVE^dtnn 


The specified device has been reserved for foreground use. 
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Table 6. Monitor Messages (cont.) 



Message 


Meaning 


! ! KEY ERROR,comments 


The Monitor could not process an unsolicited key-in response. The 
message usually indicates a format error on the key-in, where 
comments may be one of the following: 

AREA The wrong disk pack was mounted for an 
'M' key-in. 

DEVICE The channel for the device specified was not 
defined at SYSGEN or this device is not 
defined. Applies to 'M' and 'BT' key-ins. 

FIXED Performing the requested mount would entail 
undefining more than one other area. 

OVFLOW The Master Dictionary, Alternate Track 
Pool, or IOCS table length will not allow 
this key-in to be processed. 

DFN/OP The Device File table or Operational Label 
table has overflowed. 

lO ERR The device specified in the 'M' key-in cannot 
be correctly accessed. 

TEMP STACK The Temp Stack has overflowed. 


!!MACH. FAULT: TCB=FFFF, LOC=FFFF, 
X=FFFF, B=FFFF 


Direct I/O to an unrecognized device has been attempted twice 
and a watchdog timeout has occurred. 


!!MACH. FAULX: TCB-FFFF, LOC^FFFF, 
A=FFFF, X-FFFF, B=FFFF 


Direct I/O to an unrecognized device has been attempted twice at 
the same location. The foreground task subsequently is disabled 
and terminated. 


!! MESSAGE comments 


A 1 MESSAGE control command has been read. The comments field 
may contain tape mounting or other instructions. RBM continues 
to read from the CC device after the message is typed out. 


! ! PAUSE comments 


A ! PAUSE control card has been read. The comments field may 
contain tape mounting Information or other instructions. A control 
panel interrupt followed by an S key-in will cause RBM to continue 
reading from the job stack. 


! ! POWER ON 


The system has experienced a power failure, and the power fail- 
safe option has been implemented. This message is written at the 
RBM interrupt level, and consequently, any foreground tasks will 
have been completed before this messsage is typed. At this point 
the operator should terminate background, and when foreground 
is completely idle, he should reboot RBM from the RAD and 
restart the background. The message is output as soon as RBM has 
control. 
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OPERATOR CONTROL 

UNSOLICITED KEY-INS 

Because of the possible delays associated with messages to 
and from the operator/ no devices used for time-critical 
operations should time-share an I/O channel used for oper- 
ator communication. (Normally, operator communication 
is on a keyboard/printer.) All background references to the 
operator output device should be to operational label OC. 
A frequent method of operator control is in response to a 
specific request from a foreground or background program. 
In this cose, there is no standard format. 

The operator may also desire to exercise control over the 
background programs on an unsolicited basis. This control, 
termed an unsolicited key-in, is initiated by the operator 
activating the INTERRUPT switch on the Sigma 2/3 Pro- 
cessor Control Panels. This action causes an interrupt 
into the Control Panel Task. The task sets a flag in the 
RBM Control Task status word, and then issues a Write 
Direct to trigger the RBM Control Task. The Contro^ Panel 
Task then exits. 

When the RBM Control Task becomes the highest priority 
task in the system (that is, when all real-time foreground 
tasks are nonactive), it issues an output message 

!! KEY-IN 

and requests input (up to 20 characters) from the operator. 
Each key-in must be terminated with the NEW LINE © 
code. The backspace (/) and delete (EOM) codes may 
be used before the NEW LINE is typed to correct a mis- 
typed key-in. The analysis and subsequent action from the 
unsolicited key-in is performed at the RBM Control Task 
priority level. 

Specific key-in responses under RBM are: 

BL opib = DFN [,P] Permits change of operational label 

assignments during running of background programs. 

where 

opIb is an assigned operational label. 

DFN is a decimal number (00 through 53). 

P is an optional permanent change until system 
reboot. 

BL oplb = oplb Cp] Alternate version of BL oplb = DFN[,P] 

BR[dt]nn Release the specified device for background 

use. The characters representing the device type are 
optional but, if input, will be used to validate the request. 



not large enough or if dn is not a RAD device, an error 
message will be written. 

C:TCB[,COde] Connect the specified real-time fore- 

ground task to the dedicated interrupt location. 

where 

TCB is the address of the task control block for this 
task. (If the value is hexadecimal, it must be 
shown as +xxxx.) If the Overlay Loader initializes 
the TCB by means of the TCB parameters, it does 
so completely, using load information and values 
on the TCB and BLOCK cards. No partial initiali- 
zation of a TCB is allowed with the exception of 
the blocking buffer pool. If a user builds his own 
TCB, the TCB must begin at the execution loca- 
tion plus the "temp" value specified on the 
Loader !$ROOT command. 

code if present, overrides the initial code in the 

TCB for the task; a code of 7 would cause the 
level to be triggered. If code is not present, it 
will be derived from the task control block. 

CC Remove the keyboard/printer override of the CC 

device. The next control command will be read from the 
background operational label CC. This operator key-in is 
identical to the CC control command. 

CP Clear card punch and simulate an unusual end con- 
dition in the punch. The key-in is required if the card punch 
fails to recover after a JAM A or JAM B. Operator should 
first manuallyclear the punch and restore it to READY, then 
interrupt and key in CP. The last (faulty) card will be re- 
punched and cards in the normal stacker will be in the 
correct sequence. 

DB'xxxx,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, immediately dump all of background 
memory on background device DO. This key-in can be in- 
put at any time for debugging purposes. The dump will be 
in hexadecimal. 

DE Causes Debug (if Debug is part of the system) to 
request the input from the keyboard/printer. 

DF''xxxx,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, dump all of foreground on background 
device DO. The dump will be in hexadecimal. 

DM xxxx,yyyy Dump locations xxxx to yyyy if re- 

quested; otherwise, immediately dump all of RBM on back- 
ground device DO. The dump will be in hexadecimal. 



d[t]mm/dd[/yy][,hrmn] 

within RBM. 



Reset the calendar date 



BT dn, track Add track number "track" to the Alternate 

Track Pool for device dn. If the Alternate Track Pool is 



SYSGEN options (response to INC MISC query). 
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d[t]mm,dd[,yy][,hr,mn] 

D [t] mm/ddl/yy] [, h rm n] 



Alternate version of 



DR dn^ xxxx,yyyy Perform a selective dump of the RAD 

device dn to background device DO, where xxxx and yyyy 
are the first and last sectors of the block of sectors to be 
dumped. If dn is omitted, the RAD containing the SP area 
will be dumped. If dn refers to an undefined or non-RAD 
device, an error message will be written. If a 'consecutive 
series of sectors are all zeros, they will be skipped unless 
the last sector of this zero series Is yyyy^ in which case it 
will be dumped. For example, if "DR 100,200" is keyed 
in, and sectors X'1 BO' through 'X'21 5' contain zeros, X'lOO' 
through X'lCF' and sector X'2O0' will be dumped. This 
key-in applies only to the 7202 and 7204 RADs. 

The RAD dump routine performs RAD input with interrupts 
inhibited, and therefore should not be used when response 
time is critical. 



F Dump the contents of the File Control Table number 
(set in the DATA switches) on the operator's console. DATA 
switch value is DFN in hex and must be a SYSGEN number. 



FG [,Sj Must precede any job stack operation affecting 
the foreground or the operation will be aborted. This 
key-in is effective until the next !FIN or IJOB command 
is encountered. Since the key-in is normally input in 
response to a ! PAUSE command, the optional ,S key-in wil 
clear the idle state. 



FL oplb = DFNL»Pj Permits foreground operational label 

assignment changes during system operation. The changes 
will be reset to SYSGEN values upon system reboot. 

where 

opib is assigned operational label. 

DFN is a decimal number (00 through 53). 

P is an optional permanent change until system 
reboot. 



cards.) To patch program segments, DATA switch must be 
placed in the "1" state. This causes RBM to type ! ! BEGIN 
SEG XX, where xx is the segment number (xx equals zero 
for the root), and go into an idle state after each segment 
is loaded. Correctors can then be loaded to the segment 
following an H key-in. An S key-in will cause RBM to 
resume operation. Correctors modifying foreground must be 
preceded by an FG key-in. 



KP Begin reading control commands from the keyboard/ 

printer. The key-in goes into effect after the next ! !CCI 
message and stays in effect until a CC key-in or !CC con- 
trol command is encountered. 



Lar,dn[,wp] Area mnemonic "or", with a write protect 

code of "wp", will be written on sector 1 of device dn and 
sector 2 will be written with zeros, "wp" must be one of the 
following: 



blank, D, or N 

B 

F 

R 



no write protect 
background write only 
foreground write only 
RBM write only 



The L (Label) key-in is an implicit 'M' key-in. Error con- 
ditions and causes are described under the ! ! KEY ERROR 
message in Table 6. 



M ar,dn Mount area "or" on device "dn". The operator 

must mount the disk pack containing area "or" on device 
"dn" before making this key-in. Unless "or" is "Xn" the 
disk pack will be read to determine if it actually is area 
"ar". If this is true, area "ar" will be added to the Master 
Dictionary and made available for general use, including 
use by the RAD Editor and M:ASSIGN. Error conditions 
are described in ! 1 KEY ERROR message in Tabled. If 
an error occurs, area "ar" will be undefined and any areas 
implicitly "dismounted" will be undefined. 



FL oplb = oplb[,P] Alternate version of FL oplb = DFN[,P] 



FR(ilf|nn Reserve the specified device for foreground 

use. The characters representing the device type are op- 
tional but, if input, will be used to validate the request. 
The device type will be required to distinguish PT40 from 
KP40, etc. 



H Input hexadecimal corrector cards from background 

device CC. (See Appendix Gfor the format of the corrector 



SYSGEN options (response to INC MISC query). 



Q name Queue specified program for subsequent exe- 

cution in nonresident foreground. As soon as this space is 
free, the requested program is loaded. If the queue stack 
is full or if the specified program is not found in the direc- 
tory, an error message is output on the assigned foreground 
opIb, DO. 



S Continue processing if Monitor is in an idle or wait 
state. If there is a waiting background program, continue 
processing that program. If there is no background program, 
begin reading control cords from the CC device. (Monitor 
can get into the wait state from a W key-in or ! PAUSE com- 
mand or into Idle from a !FIN command.) 
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SY[,S] Permit modification of system files on the RAD 

to take place until the next IJOB or I FIN command is en- 
countered. This key-in is a double check (similar to the 
FG key-in) to prevent accidental destruction of the RAD 
files. Since this key-in is normally input in response to a 
I PAUSE command, the optional ,S will clear the idle state. 



T HRMN Reset the RBM system time. 



T HR.MN Alternate version of T HRMN. 



intervention cannot take place while there are active fore- 
ground programs/ and will be delayed until they terminate. 



Background goes into a wait state. 



X Abort the background job with any dumps requested, 
and output error code OP and a printed message showing 
the location of last background instruction executed. If 
the Postmortem Dump program is active, it will also be 
terminated. 



UL Force an unload of the program occupying the non- 

resident foreground area. Note that operator key-ins can 
interrupt the background program at any time. Operator 



Z Terminate the current background {ob including the 

Postmortem Dump program without performing postmortem 
dumps (abort code ER is output). 
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4. MONITOR SERVICE ROUTINES 



BRANCHING TO SERVICE ROUTINES 

Under RBM, foreground and background programs may make 
colls on the Monitor to perform various services or privi- 
leged operations. (See Table 7.) For background requests, 
a branch to protected memory will trigger the protection 
routine which examines the branch for validity. If the 
protection violation is one of a permissible set of "con- 
trolled" violations, the branch is permitted; otherwise, the 
background job is aborted with a suitable error message 
giving the location to which the branch was attempted. If 
the branch is valid, the protection routine will permit the 
branch to the appropriate Monitor service routine. 



All service routines are completely reentrant. Hence, they 
can be used by multiple tasks on a completely independent 
basis. Table 7 shows the routines requiring temporary space 
in the user's temp stack. 



There are two different methods of executing a branch to 
one of these Monitor service routines: the conventional 
method Is to declare the service routine name as an ex- 
ternal reference and have the Overlay Loader satisfy the 
reference at load time. (In this case, the address lit- 
eral will be In the user's program, and will be filled in 
by the Overlay Loader.) The other method Is to branch 
indirectly through the address literal In the zero table 
(see Appendix B) using the absolute address given in 
Table 7. This is a useful technique for an absolute fore- 
ground program assembly, or for a processor or other pro- 
grams that are self -re locating. 



Actually, portions of the above routines are resident. The 
resident portion of M:CLOSE, for example. Is as follows: 



M:CLOSE 



RCPYI 

B 

DATA 



Q:ROC 
'ID NN' 



where 



ID represents the segment Identifier of the non- 
resident overlay section of M:CLOSE. 



NN 



is the temp stack requirement. 



Q:ROC will call M:RES to reserve the appropriate amount 
of temp space, will read in the required segment, and will 
transfer control to the overlay routine which runs and re- 
turns to Q:ROC. Q:ROC will reload the overlay area If 
appropriate and will then release the temp space and re- 
turn to the caller by a call to the Monitor service routine 
M:POP. Any calls to the above Monitor service routines 
will require use of the RAD; therefore, the requesting task 
must provide In Its TCB for use of the RAD. In addition, 
particular attention should be given to the maximum tempo- 
rary stack requirements of these routines. 



SERVICE ROUTINES 



The B register is always saved and restored since it is used 
to point to temporary space. All other registers are volatile. 
The return address (specified by the L, T, or A register) 
must point to the background area If the routine is called 
(branched to) from the background. Otherwise, a protec- 
tion violation abort occurs. 



Certain Monitor service routines are nonresident overlay 
routines. The Monitor subroutine QrROC controls the load- 
ing of the RBM overlay area. The following Monitor service 
routines are nonresident overlay routines: 



M:iOEX 



(General I/O Driver) 



M:ASSIGN 

M:CLOSE 

M:COC 

M:CTRL 

M:DATIME 

M:DEFINE 



M:DOW 

M:LOAD 

M:OPEN 

M:RSVP 

M:WAIT 



M:IOEX provides direct control by background programs, 
the Monitor, or foreground real-time programs over all 
I/O operations on the buffered I/O channels for centraliza- 
tion of I/O Interrupts. All M:IOEX control functions are 
exempt from channel time limits. The calling sequence Is 



LDX 

RCPYI 

B 



ADRLST 

P,L 

M:IOEX 



ADRLST Is a pointer to the argument list, which is a set 
of two, three, or four consecutive words In the user's 



If the overlay area was originally occupied by an active 
Monitor service routine, the routine must be reloaded. If 
the requested routine Is the one occupying the overlay area, 
no loading will be required. 
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Table 7. Transfer Vector for Monitor Services 



Adc 


Iress 


ADRL for 


Purpose of This Routine 


Words of Temp Required 


Dec. 


Hex. 


Min. 


Max. 


199 


C7 


M:FSAVE 


M:SAVE Function if Register Previously Saved 








200 


C8 


M:IOEX 


Device-Dependent I/O Driver 


16 


16 


201 


C9 


MrREAD 


Device-Independent Read Routine 


25 


38 


202 


CA 


M:WRITE 


Device-Independent Write Routine 


25 


38 


203 


CB 


M:CTRL^ 


Device-Independent Control Routine 


16 


43 


204 


CC 


M:DATIME^ 


Calendar Date and Time of Day 


18 


18 


205 


CD 


M:TERM 


Normal Termination of Background 








206 


CE 


M:ABORT 


Abnormal Termination of Background 








207 


CF 


M.-SAVE 


Save Registers on Real-Time Interrupt 








208 


DO 


M:EXIT 


Restore Registers on Foreground Exit 








209 


Dl 


M:HEXIN 


Hexadecimal to Integer Conversion 








210 


D2 


MrlNHEX 


Integer to Hexadecimal Conversion 








211 


D3 


MrCKREST 


Checkpoint/Restart Background 





52 


212 


D4 


MrLOAD^ 


Load Nonresident Foreground 


13 


13 


213 


D5 


M:OPEN^ 


Open Blocking Buffer for RAD File 


13 


13 


214 


D6 


M:CLOSE* 


Close Blocking Buffer for RAD File 


14 


14 


215 


D7 


M:DKEYS 


Read Data Keys 








216 


D8 


M:WAlf 


Execute Wait Loop From Background 


15 


51 


217 


D9 


M:SEGLD 


Load Overlay Segment 


35 


63 


218 


DA 


MiDEFINE^ 


Define RAD Files in Background Temp Area 


13 


13 


219 


DB 


M:ASSIGN^ 


Assign Operational Labels 


18 


56 


220 


DC 


M:POP 


Release Dynamic Temp Space 








221 


DD 


M:RES 


Reserve Dynamic Temp Space 








222 


DE 


M:OPFILE 


Convert Operational Label to Device-File Number 








223 


DF 


M:RSVP^ 


Reserve or Release Peripherals 


20 


51 


224 


EO 


M:DOW^ 


Diagnostic Output Routine 


13 


51 


225 


El 


MiCOC*" 


Communications Handler 


25 


25 


These 


routines ore nonresident RBM overlays. All nonresident RBM overlays require a minimum 


of 13 temp cells to load 


the ro 


utine. 




Notes 


: 1. To branch to one of these routines, branch indirectly through the specified address 
(except M:RES which Is called following an RCPYI PJ). 


above after RCPYI P,L 




2. The minimum temp space required is the number used by the routine itself. The maximum temp space is the 
number required by this routine and those it calls. For example, M:READ (25) may call M:OPEN (13) to 
open a blocking buffer. This call would require 38 temp cells. 




3. Under normal usage, M:SEGLD requires a maximum of 35 temp cells. However, 6 
the message ! ! BEGIN SEG xx. This Is an RBM assembly option (i.e., Debug = ye 


are required to output 
s). 




4. MrCKREST requires 52 temp cells if the checkpoint is performed at the priority lev< 


;! of the calling task. 




5. Use of any device that has nonresident pre-I/O and post-I/O edit routines and nonre 
tines associated with it requires 38 tempcellsbyM:READ/M:WRITE. These include KP 


sident error recovery rou- 
, PT, LP, B7, CR, andCP. 
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program or in a temporary stack. This argument list ap- 
pears as follows: 

word 



F 


A 


Z 





OP 



12 3 



12 13 



15 



where 



F = if word 1 is an operational label or device 
unit number. 

A = 1 if AIO Receiver is specified in word 3 (fore- 

ground option only). 

A = if no AIO Receiver is specified (three-word 
call, then). 

X - ] if AIO Receiver is acknowledged on zero 

byte count interrupt. 

Z = if acknowledged on channel end only. 

OP is the code for the operation to be performed: 

for SIO 

1 for TIO 

2 for TDV 

3 for HIO 

4 for "check previous data transfer" 



word 1 



Operational label or file number 



15 



word 2 



Address of first lOCD (for SIO only) 



15 



word 3 



Address of AIO Receiver (for SIO only) 



15 



Return is to the location in the L register on the call 
to M:IOEX. B register is always saved. 

The Overflow (OI) and Carry (CI) Indicators, the A register, 
E register, and (in some cases) X register are used to return 
status information on the required operation. The complete 
list of status codes is given in Table 8. In this table, DSB 
stands for Device Status Byte, OSB for Operational Status 



Byte, Byte Count Residue is from the even I/O channel 
register at channel end, and Dev.No. stands for the device 
number of the current device. 



Note that no I/O error recovery has been attempted. DSBs 
and OSBs are just as received from the I/O system hardware. 
These status returns are organized so that a quick and simple 
test will show the nature of the return. If the user wishes 
to keep trying to initiate the I/O operation or keep check- 
ing for completion, it is possible to loop back to the call 
to M:IOEX. 



The user can use M:IOEX to read/write on the RAD or 
any peripheral device that uses standard Xerox Sigma pe- 
ripheral responses. For input/output operations to the 
RAD, the user must first give a seek order and then the 
appropriate data-transfer request. The user must also 
perform his own file management. If multiple tasks use 
the RAD, they must cooperate in some way so that the seek 
address is not modified, by some higher-level task before the 
data operation is initiated. Note that a user must always 
issue a "Check/Write" (op code of 4) after each read or 
write request. 



The following rules govern the use of M:IOEX for a RAD: 

1. A device-file name of the form XXdn must be included 
in the set of SYSGEN input parameters following the 
heading DEVICE FILE INFO, where XX indicates that 
this is a special -purpose device for use with M:lOEX, 
and dn is the hardware device number of the RAD. The 
M:IOEX calling sequence must contain the device-file 
number corresponding to this device-file name, or must 
contain an operational label that is assigned to the 
device-file number. 



The set of SYSGEN input parameters following the 
heading RAD ALLOCATION must include provisions 
for reserved tracks that are not to be included in the 
areas allocated for RBM file management. This can be 
accomplished by 

a. Assigning the system RAD to a device number other 
than XXdn. This method requires two RADs, one 
containing the RBM area assignments, and the other 
available for use with MrlOEX. 

b. Allocating only part of a RAD for RBM area assign- 
ments, leaving the remainder available for use 
with M:IOEX. 



c. Allocating part of a RADfor M:lOEX use by speci- 
fying that a number of tracks be skipped between 
RBM areas with an allocation parameter of SK = n, 
where n is the number of tracks. 

d. Any meaningful combination of the above. 
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Table 8. Return Status from M:IOEX 



Operation 


Major Status 


OI 


CI 


E Register 


A Register 


X Register 





1 -7 


8-15 


0-7 


8-15 


0-15 


SIO, TIO, 
TDV, HIO 


Device number 
not recognized 


1 


1 







Recognition Code 







All 


Invalid call or opib 








1 




4 or 8 







opib equals zero 













2 







SIO 


SIO cannot be 
accepted 





1 





Current file 
Number 


TIO 


Dev. No, 





Channel busy 











Active file 
Number 


DSB 


Dev. No. 


-1 


Successful 
initiation 











Current file 
Number 


SIO 
DSB 


Dev. No, 





TIO 


SIO cannot be 
accepted 





1 





Current file 
Number 


TIO 
DSB 


Dev. No. 






Other 











TDV 


Device abnormal 
condition 





I 





Current file 
Number 


TDV 
DSB 


Dev, No, 




Device normal 
condition 













HIO 


Device operating 
when HIO 
received 





1 





Current file 
Number 


HIO 
DSB 


Dev. No. 




Device not oper- 
ating when HIO 
received 













I/O check 


l/O operation 
in progress 


1 








Current file 
Number 


SIO 
DSB 


Dev. No. 






I/O completed 
unusual end 





1 





E 

Flag 

(Bit?) 


OSB 


AIO 
DSB 


Dev. No. 


Byte Count 
Residue 


I/O completed 
normal end 











Use BXNC to test both conditions simultaneously. 
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M:IOEX FUNCTIONS 

TIP, TDV, mo In these operations, the request is per- 
formed immediately and the device status bytes are returned 
if the device is recognized. The AIO Receiver is ineffec- 
tive for these operations. 

SIO The SIO operation is initiated if there is device 
recognition and the channel is free (which may not be the 
same as "device free" or "device controller free" for chan- 
nels with several devices). 

The SIO is issued even if the device is in the manual mode. 
It is therefore the responsibility of the user's program to test 
for the manual mode both before and after the SIO request, 
and to inform the operator by a suitable message. 

An HIO can be used to abort an I/O operation. This results 
in setting the channel end device ready for a new activity. 
Since status is returned, an I/O check operation is not 
returned. 

Protection checks are performed only for background I/O 
requests. Background is not permitted an AIO Receiver, 
and a receiver is ignored if requested from the background. 
Background operations specifying data chaining are not 
allocated. This Is due to the structure of the lOCDs, I/O 
Data Tables, and the requirements for the absolute protec- 
tion of foreground programs (see "End Action" In Chapter 5). 

If the request for I/O action is for an odd number of bytes, 
the order byte must be properly set in the right half of the 
word, as specified In the Sigma 2 and Sigma 3 Computer 
Reference Manuals. MrlOEX does not move any data or 
order bytes. 

When using foreground data chaining, it is very important 
to set the interrupt flags on all lOCDs except for the one 
pointing to the "order" byte, since an unusual end condi- 
tion In one of the lOCDs without the interrupt flag being 
set will cause the I/O to terminate without an interrupt, 
and the channel may then "hong up" waiting for the In- 
terrupt because the RBM tables indicate that the channel 
is still busy. 

The Monitor does not alter the user's data in any way. If 
an I/O interrupt is received and there is no AIO Receiver 
specified (and the device is still busy), the I/O interrupt 
is ignored and the channel remains active. 

The user's program must determine whether there was a 
channel end or an unusual end condition. If the return is 
for a busy device or channel, the program can loop on this 
request until the operation is successful. 

Since only higher priority tasks can take control from the 
task issuing the request, the routine Issuing the request 
gains control of the desired device and/or channel as soon 
as the current operation Is complete. The MrlOEX routine 
Inhibits interrupts for a period of less than 100 microseconds 
during the loading of the I/O channel registers and the set- 
ting of the activity status for the device and channel. Thus 



a higher priority task can always interrupt up to the point 
when the I/O channels are loaded during the Initiation of 
an I/O request. 



I/O CHECK This operation tests for channel end on the 
previously requested I/O operation by testing certain flags 
within the RBM I/O tables. The flag is set by the I/O In- 
terrupt task when the device Interrupt occurs. Thus, no 
TIOs are required to determine when the operation Is com- 
plete. Since the TIOs do consume some I/O time (particu- 
larly if executed repeatedly In a test loop), the method of 
checking for I/O completion described herein Is desirable. 
The Monitor saves the operational status byte and the byte 
count residue from the completion of the I/O operation, 
even though another device may have used the channel be- 
fore the end-action check is made by the requesting task. 



The following restrictions are pertinent in using M:IOEX: 

1. RBM will not necessarily recover automatically from 
the results of an HIO for most devices. Operator In- 
tervention may be necessary. 

2. Background programs cannot specify data chaining. 

3. Background programs must specify an interrupt. 



M:READ 



(General Read Routine) 



MrREAD provides device-Independent Input with standard 
editing and checking. Standard error detection and cor- 
rection is optional on each call. The calling sequence Is 



LDX 


ADRLST 


RCPYI 


P,L 


B 


M:READ 



ADRLST Is a pointer to the argument list, a set of two to 
six words In the user's program or in a temporary stack. 
This argument list appears as: 

word 



F 


A 


W 


E 


R 





ORDER 



1 2 3 4 5 



7 



15 



where 

F = 1 If a device-file number Is specified. 

F = If an operational label or device unit number 

Is specified. 

A = 1 if an AIO Receiver address is specified 

(specifiable by foreground only). 

A = if no AIO Receiver Is specified. 
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W = 1 if wait for completion is unconditional. 



word 3 



W = if wait is for "initiate and return" only; 
return is immediate if operation cannot be started 
at once. (The minimum-seek algorithm does not 
apply to RAD "no wait" operations.) 



E = 1 



if standard error recovery is to be performed 



at channel end. 



E = if no error recovery is to be attempted. 

R = 1 if a RAD granule displacement is specified 

(can only be specified for random-access RAD 
files). 

R = if a RAD granule displacement is not 
specified. 

ORDER is one of the following permissible pseudo 
input orders: 

Order Operation 

X'OO' Return information about this device 
and file. 



Number of bytes to transmit 



15 



Byte count must be an even number when reading from RAD 
files and cannot exceed 65,536. For all other devices the 
byte count may be either even or odd but cannot exceed 
8192. If the byte count is even, input data stored in the 
user's buffer starts in the left-hand byte; if odd, data starts 
in the right-hand byte. 



word 4 



AIO Receiver address or RAD granule displacement 



15 



If A = 1 (in word 0), this is the address of the closed AIO 
Receiver subroutine called by the I/O interrupt task at 
channel end. If A = 0, this is the RAD granule displacement 
(see word 5). 



word 1 



word 2 



X'02' Read binary. 

X'04' Check previous input for completion 
(after a "no wait" initiation). 

X'06' Read automatic. 

X'OC Read backward (9-track magnetic 
tape only). 



word 5 



Operational label or file number 



15 



Address of buffer to receive data 



15 



Buffer must be in background if called by a background 
program. Also, buffer must not overlap active temporary 
storage or unavailable memory. 



For magnetic tapes, RAD, or disk pock, five attempts 
for error recovery will be made if E is specified. If I/O 
without a WAIT is specified, error recovery will not be 
performed until a "Check/Write" is issued by the user. 



RAD granule displacement (optional) 



15 



If an AIO address is specified (A = 1 in word 0), word 5 
indicates the displacement of the granule from the start of 
the file (starting with a displacement of zero) where the 
I/O transfer begins. Word 4 is the RAD granule displace- 
ment if A = 0. 

Return is always to the location specified in the L register. 
The B register is always saved. 

The E, A, and X registers all contain status information on 
the return, as shown in Table 9. I/O completion codes 
are listed in Table 10. Return is always immediate if there 
is a calling sequence error, in which case the E register is 
negative upon return. For the case where a wait is speci- 
fied, the I/O is initiated and the M:READ routine loops 
until the operation is complete. When "initiate and no- 
wait" is specified, an SIO is issued before the return if the 
device is recognized, is currently free, can accept on SIO, 
and is not in the "manual" mode (unless M = 1 in word 0). 
If any one of these conditions is false, the M:READ routine 
returns immediately with the appropriate indicators set. If 
the channel or device is busy, the caller can either loop 
back to the call to M:READ or switch to another device. 
The "wait" flag has meaning whether this is an initiate or 
a check order. Error recovery is attempted if specified 
before the final return is made. 

On a check operation, the byte count returned in the X 
register may not be meaningful if the calling sequence does 
not specify the some count as the initial read. If the order 



32 



Service Routines 





Table 9. Return Status from M:READ, MiWRITE 


M:CTRL 






Operation 


Major Status 


Action 


EReg. 


A Reg. 


XReg. 


All operations 


Operational labels not 
valid 


Return immediately 


-1 


8 






Calling sequence error 


Return immediately 


-1 


4 






Operational label is set 
to zero 


Return immediately 





2 






Unrecoverable l/O error 


Return after error recovery 
attempt, if any 


-1 


1 






Illegal sequence of RAD 
operations 


Return immediately 





9 






Blocking buffer not 
available 


Return immediately 





10 




Initiate l/O 
and no wait 


Channel and device are 
free and in automatic 


Initiate l/O and return. 
Status in X register only 
meaningful if A=l in the 
call. X = -l if the AIO 
Receiver will not be ac- 
knowledged; otherwise, 
X = 0. 








Oor -1 




Channel and/or device 
are busy 


Return immediately 





-1 


t 




Manual intervention is 
required (manual mode 
or no device recognized) 


Return immediately 


-I 


-1 


t 


Check and 
no wait 


I/O still in progress 
I/O complete 


Return immediately 

Return after end- 
action, if any 



Oor -1 


-1 

comple- 
tion code 


t 

Byte 
count 


Initiate and 
wait 


Channel and device are 
free and automatic 

Channel or device 
are busy 

Device number is not 
recognized or is write- 
protected 

Device is in manual 
mode 


Initiate l/O and wait 
for completion 

Wait and keep trying 

Type out the proper 
message to operator 
and retry 

Type out EMPTY mes- 
sage to operator and 
retry 








Initiate and 
wait or check 
and wait 


l/O still in progress 


Wait, and keep 
checking 




l/O complete 


Perform any end- 
action and return 


Oor -1 


comple- 
tion code 


Byte 
count 
trans- 
mitted 


Unspecified 
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Table 10. I/O Completion Codes 



E Reg. 


A Reg. 


Meaning 


Comment 








Operation successful. 


X register contains the number of data bytes 
transmitted. 


-1 


1 


Unrecoverable I/O. 


If error recovery was specified, the maximum number 
of retries have been unsuccessfully attempted. 





2 


Operation not meaningful for 
this device. 


Either an operational label was assigned to file zero 
or I/O operation is not meaningful for the device. 





3 


End-of-file encountered. 


Significant only for magnetic tape and sequential RAD 
files (except in automatic mode when significant also 
for cards, paper tape, and keyboard/printer). 





4 


End-of-tape encountered. 


Significant only for magnetic tape or sequential and 
random-access RAD files. 





5 


Incorrect record length. 


For read operations, the requested byte count does not 
equal the device's physical or logical record size. For 
write operations, the requested byte count is greater 
than the device's physical or logical record size. For 
either read or write, the actual byte count transmitted 
is returned in the X register. 





6 


No I/O pending for this check 
operation. 


Error in I/O buffering. An initial no-wait I/O request 
either was not issued or was rejected. 





7 


Device is write -protected. 


Significant only for writing on magnetic tapes and RAD 
files. 





8 


Beginning-of-tape encountered. 


Significant only for reading backward and for position- 
ing magnetic tapes and sequential RAD files via 
MrCTRL. 





9 


Illegal sequence of RAD 
operations. 


Significant only for sequential RAD files. 





10 


Blocking buffer unavailable. 


Significant only for blocked or compressed sequential 
RAD files. 



code is X'OO', the following device status information is 
returned: 

Register Status Information 

A Device name (EBCDIC). 

E TDV device status byte (bits 0-7) and physi- 

cal device number (bits 8-15). 

X Physical standard record size (bytes) for non- 

RAD files or granule size for RAD files. 



record is EBCDIC or binary. Therefore, M:READ will set 
up the proper order bytes for the actual device, using the 
"pseudo order byte" given in the call to M:READ only as 
a guide. The user may request fewer bytes than are in the 
record and only this number will be returned in his buffer. 
However, if more bytes are requested than are in the rec- 
ord, only the bytes in the record will be read. In any 
case, the actual number of bytes read will be returned in 
the X register when the completion code is returned, and 
if this is not the same as the number of bytes requested, an 
"Incorrect length" code will be returned. While it is not 
always necessary for the user to check all possible return 
codes, it may be useful to print them out to aid in debugging. 



M:READ FUNCTIONS 

M:READ Is designed to read one physical record from the 
specified device regardless of device type and whether the 



Using M:READ, a user can read 80 EBCDIC bytes regardless 
of whether they come from cards, paper tape, magnetic 
tape, keyboard/printer, or RAD. MrREAD will perform 
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standard edUing from paper tape to give a record a format 
identical to card image output. 

By using a "read and no wait" followed later by a "check 
for input complete" the user can effectively overlap input 
and compute. 

The order code X'OO' is used to request informdtion about 
an unknown device, and may be helpful in determining the 
optimum blocking sizes to use. 

REAL-TIME PRIORITY 

All of the I/O routines are reentrant, and any input can be 
interrupted for a higher-priority task up to the "point of no 
return" of setting Monitor status flags and loading channel 
registers. External and internal interrupts are inhibited for 
up to 100 microseconds of CPU time during the actual SIO 
sequence. Keeping a high priority task active and looping 
on an Input request to a busy device enables the task to 
seize control of the channel or device as soon as the cur- 
rent I/O operation completes. 

SPECIAL EDITING FOR CARD READER 

Read Automatic. Any cards with a " V and "2" punch in 
column 1 are automatically read as binary; all other cards 
are read as EBCDIC or BCD. (For nonstandard binary cards, 
the user must use "read binary".) It is possible to specify 
that all cards from a certain file are to be read as BCD and 
converted by the M:READ routine to EBCDIC before being 
returned to the user. Since this would apply only to one 
file, it is possible to read some cards in EBCDIC and some 
in BCD from the card reader. (BCD card codes are pro- 
duced by an IBM 026 keypunch, and EBCDIC card codes 
are produced by an IBM 029 keypunch.) The EBCDIC 
record size is 80, and the binary record size is 120 bytes. 

An incorrect length status is returned if the requested byte 
count does not exactly match. An "end-of-file" status is 
returned when an EBCDIC card that begins with !EOD is 
input into the user's buffer. An "end-of-tape" status is 
never returned. 

Read Binary. An "incorrect length" status is returned if 
the requested byte count does not equal the maximum num- 
ber of bytes requested in the calling sequence. The num- 
ber of bytes requested, up to a maximum of 120, are input 
in the user's buffer. "End-of-file" and "end-of-tape" status 
codes are never returned. 



SPECIAL EDITING FOR PAPER TAPE OR KEYBOARD/ 
PRINTER 

Read Automatic. All input from paper tape or keyboard/ 
printer is initiated in a one-byte-at-a-time mode. From 
paper tape, the read order is always "read ignoring leader". 
If the first byte is a code of X'lC, X'3C', X'FF', X'9F', 
X'BF', X'DF', or X'78' (which can only happen with paper 
tape), the M:READ routine switches to a binary mode and 



reads up to 1 19 more bytes (for a total of 120 in the record). 
The code byte will be the first byte in the user's buffer. 

Code bytes are all invalid EBCDIC codes in the sense that 
they are not printable graphics or control codes. Since 
they are all supersets of the card reader "1 and 2 punch" 
rule for column one, the same codes for "read automatic" 
can be used for the card reader as for paper tape and, in 
both cases, the code is part of the user's data buffer. If 
the first byte from the paper tape or keyboard/printer is not 
one of the binary codes M:READ continues to read one byte 
at a time until a NEW LINE code is encountered. 

When a NEW LINE code is encountered, input transmission 
is terminated and the line image is filled out with blanks 
to the requested byte count. The NEW LINE code is not 
transmitted to the user's buffer. (If a NEW LINE code is 
the first code in the input line, it is ignored.) 

Thus, all EBCDIC records are of variable length, up to the 
maximum requested or until a NEW LINE is encountered. 
Further, EOM and cent (^) have special meanings within 
the user's data line. An EOM causes the entire line up to 
the present position (including the EOM byte) to be dis- 
carded. A ^ sign acts like a backspace. For each f^ sign 
received, this byte and the byte preceding it are thrown 
away. 

Whenreading binary records in the automatic mode, 120 bytes 
are read regardless of the number of bytes requested. For 
EBCDIC records, the paper tape is read up to and including 
the NEW LINE code. For either EBCDIC or binary records, 
not more than the maximum number of bytes requested is 
transmitted to the user's buffer. The requested byte count 
must be 80 for EBCDIC records and 120 for binary records. 
Any other byte counts result in an "incorrect length" 
status return. 

An "end-of-file" status is returned when an EBCDIC record 
that begins with !EOD is input into the user's buffer. 

Read Binary From Paper Tape. The Read Binary order for 
paper tape is "read ignoring leader". The physical record 
size is the number of bytes requested by the user's input. 
The next record starts immediately following the last byte of 
the previous record and the requested byte count determines 
the end-of-record. "Incorrect length" and "end-of-file" 
status codes are never returned. "End-of-tape" status is 
not returned, even when the paper tape runs off the reader. 

Read Binary From Keyboard/Printer. A read binary order 
causes the keyboard/printer to read the exact number of 
bytes specified. RBM performs no editing, and no bytes 
(Including NEW LINE codes) are considered control bytes. 
"Incorrect length", "end-of-tape", and "end-of-file" 
status codes are never returned. 



SPECIAL EDITING FOR MAGNETIC TAPE 



Read EBCDIC or binary. Binary and EBCDIC modes are 
identical on 9-track tape, and M:READ supports only the 
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BCD and packed-binary modes for 7-track tapes. Only the 
number of bytes requested is transferred to the user's buffer 
regardless of the physical record. "Incorrect length" status 
is returned when there are either too few or too many bytes 
in the input record, and the tape is positioned at the start 
of the next physical record. 

"End-of-file" status is returned when a file mark is sensed 
on the magnetic tape; "end-of-tape" status, when the phys- 
ical end-of-tape mark is sensed and standard error recovery 
is specified. If both are sensed at the same time, the "end- 
of-tape" status is returned. 

The Read Backward order produces a buffer with data in an 
inverted condition. If the tape Is at the load point when 
the Read Backward order is given, no data is transmitted 
and "BOT" status is returned. Read Backward will be 
ignored for devices other than 9-track magnetic tape. 

SPECIAL EDITING FOR SEQUENTIAL RAD FILES 

Read Automatic or Binary. On a RAD, binary and EBCDIC 
modes are identical. When reading from blocked files, a 
blocking buffer must be supplied. If the calling program 
has not specified a blocking buffer, M:READ will call 
M:OPEN to reserve a buffer from the calling task's buffer 
pool. If no buffer is available, M:READ exits with a 
"blocking buffer unavailable" status. 

Compressed records are decompressed by M:READ so that 
only the expanded record, without compression codes, is 
input into the user's buffer. 

A byte count can be requested that is less than, equal to, 
or greater than the file's logical record size. The number 
of bytes requested, up to a maximum of the logical record 
size, is always transferred. If the byte count does not equal 
the logical record size, "incorrect length" status is returned. 
In any case, the file is positioned to the next logical record, 
regardless of the byte count transferred. For compressed 
files, the requested byte count is compared to the byte 
count of the expanded record instead of the logical record 
size. "End-of-file" status is returned when the file is 
positioned at the logical EOF. "End-of-tape" status is 
returned when the file is positioned at the logical EOT. 
This is true whether or not error recovery is specified. 

A Read Backward order will be interpreted as a Read order. 

SPECIAL EDITING FOR RANDOM-ACCESS RAD FILES 

Read Automatic or Binary. Binary and EBCDIC modes are 
again identical. The exact number of bytes requested will 
be put into the user's buffer and "incorrect length" status 
will not be returned. One or more granules will be read to 



satisfy the byte count. RAD space between granules is lost. 
Unused parts of granules are ignored. 

If the Read begins or extends beyond the file's ending 
boundary, no data is transmitted and "end-of-tape" status 
is returned. This is true whether error recovery is specified 
or not. The granule displacement must always be specified; 
if not, a "calling sequence error" Is returned. 

Note: For all RAD files, no transfer will be Initiated that 
crosses a track boundary. Instead, it will be broken 
into two transfers: one to write to the end of the 
track, and a second to complete the transfer. There- 
fore, In a "no-wait" operation, a check must be 
requested to complete the transfer. If an AIO Re- 
ceiver is specified. It will be entered each time 
channel end occurs, but it also must be specified In 
each Check operation call. 



M:WRITE (General Write Routine) 

MrWRITE provides independent output with standard editing 
and standard error detection and correction. The error 
handling procedure is optional on each call to M:WRITE. 
The calling sequence is 

LDX ADRLST 

RCPYI P,L 

B MrWRITE 

ADRLST is a pointer to the argument list, which is a set of 
two to six words in the user's program or In a temporary 
stack. The argument list consists of six words: 

word 



F 


A 


W 


E 


R 





ORDER 



12 3 4 5 



7 8 



15 



The user should be thoroughly familiar with the BCD and 
packed-binary mode if 7-track magnetic tape is used. See 
the 7-Track Magnetic Tape System Reference Manual, 
Publication 90 09 78). 



where 

F = 1 if a device-file number is specified. 

F = if an operational label or device unit is 
specified. 

A = 1 If an AIO Receiver address is specified. 

A = If no AIO Receiver address Is specified. 

Note: only a foreground operation can specify 
this. 

W = 1 if wait for completion Is unconditional, 

W = if wait is only for "initiate and return"; 
return is immediate if the operation cannot be 
started immediately. 
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E = 1 if standard error recovery is to be performed 

at channel end for this operation. 

E = if no error recovery is to be attempted. 

R= 1 ifa RAD granule displacement is specified (can 

only be specified for random-access RAD files). 



v/ord 4 



R = if a RAD 


granule displacement is not specified. 


ORDER is one 


of the following pseudo order bytes: 


Order 


Operation 


X'OO' 


Return information about this device. 


X'Ol' 


Write binary. 


X'03' 


Write file mark or !EOD. 


X'04' 


Check previous input for completion 




(after a "no wait" initiation). 


X'05' 


Write EBCDIC. 


X'07' 


Check write (RAD only). 


word ] 




Operational label or file number 



15 



word 2 



Address of buffer containing data 



15 



word 3 




Number of bytes to transmit 



15 



The byte count must be an even number when writing on 
RAD files and may not exceed 65,536. It may be either 
even or odd for all other devices, but cannot exceed 
8192 bytes. If an odd byte count is requested, the first 
byte is written from the right half of the word and the left 
half is ignored. If an even byte count Is requested, the 
byte is written from the left half of the first word. 

Output to the card punch assumes an even byte count. An 
extra byte at the start of the buffer is sent if the count is odd. 



For magnetic tapes, RAD, or disk pack, five attempts 
for error recovery will be made if E is specified. If I/O 
without a WAIT is specified, error recovery will not be 
performed until a "Check/A^rite" is issued by the user. 



AIO Receiver address or RAD granule displacement 



15 



This is the address of the closed AIO Receiver subroutine 
called by the I/O interrupt task at the channel end, if 
A = 1 (word 0). If A = 0, this is the RAD granule displace- 
ment (see word 5). 

word 5 



RAD granule displacement (optional) 



15 



If an AIO address Is specified (A = 1, word 0), word 5 
indicates the displacement of the granule from the start of 
the file (starting with a displacement of zero) where the I/O 
transfer begins. If A = 0, word 4 is the RAD granule dis- 
placement. See Chapter 6 for further details. 

The return is to the location In the L register. The B regis- 
ter is always saved. 

The status is returned in the E, A, and X registers. Status 
and method of returning status are the same as for M:READ, 

MrWRITE FUNCTIONS 

M:WRITE is designed to write one physical record on the 
device specified, regardless of the device type. Because 
of differences in Write orders for the card punch, it is 
necessary to specify whether the output record is binary or 
EBCDIC. (For most other devices, the difference is not 
meaningful.) 

Not more than one physical record will be written for a 
single Write order. For devices like the card punch, if 
fewer than a standard number of bytes are specified (80 for 
EBCDIC and 120 for binary), the remainder of the record 
is padded with blanks (EBCDIC) or zeros (binary). Most of 
the general comments which apply to M:READ also apply to 
M:WRITE. 

Write End -of -File. Order code X'03' produces the fol- 
lowing results: 



Device 

Line Printer 
Keyboard/Pri nter 
Card Punch 
Paper Tape Punch 
Magnetic Tape 
RAD (sequential file) 
RAD (random file) 



Result 

No effect 

No effect 

! EOD card 

lEOD NL 

EOF 

Logical file mark 

Logical record mark 
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For devices where the Write End-of-Flle order has no mean- 
ing, a status of "operation not meaningful for this device" 
will be returned. If a magnetic tape or sequential RAD file 
is positioned at the end-of-tape, the end-of-file will be 
output. (This is the only writing allowed past the end-of- 
tape when error checking is specified.) The Write End-of- 
File order for any RAD file causes an implicit call to 
M:CLOSE and any data written in the blocking buffer will 
be output on the RAD. 

Write EBCDIC to Keyboard/Printer. The first byte is as- 
sumed to be a carriage control byte and is never printed. 
If the byte is a zero or a one, double spacing is used; other- 
wise, single spacing is used. In any case, this first byte 
is not sent to the keyboard/printer. Trailing blanks are 
removed and a NEW LINE code is inserted as the last byte 
(if NEW LINE is not already present). If there are more 
than 85 printable characters, those beyond 85 are ignored, 
and a status of "Incorrect length" is returned. 

Write Binary to Keyboard/Printer. The exact number of 
bytes specified is written. No format byte is assumed, no 
editing is performed, and no line format is imposed. It is 
the user's responsibility to insert NEW LINE codes If more 
than 85 bytes are output. A maximum of 256 bytes may be 
output with one operation. 

Write EBCDIC to Paper Tape. Trailing blanks are removed 
and a NEW LINE code is inserted as the last byte (if not 
already present). The entire record, specified by the byte 
count, is edited and output and an "incorrect length" status 
is never returned. 

Write Binary or EBCDIC to Line Printer. The first byte per 
record is always assumed to be a carriage control (format) 
byte, and is never printed. With any odd byte count (as in 
all of the I/O), the first byte transmitted is from the right 
half of the first word, and the left half of the first word is 
ignored. 

The print routine changes the logical format byte (as shown 
below) to the proper physical format code for the printer. 
If more than 133 bytes are specified, the remainder beyond 
133 bytes is Ignored and an "incorrect length" status re- 
turned. If fewer than 133 bytes are specified, the right 
(trailing) portion of the printed Image will contain blanks. 
However, the user's buffer is not modified. The print rou- 
tine will first data chain on the order byte and format byte 
in the Monitor area and then on the user's print image. 

If it is desired to force single spacing, there may be a word 
appended to the beginning of the user buffer with a blank 
in the right half; the byte count is then Increased to an odd 
value, and up to 132 bytes from the original buffer will be 
printed with the extra "blank" used as the format byte to 
force single spacing. The format codes (in EBCDIC) are 

Format Byte Effect 



Format Byte Effect 

1 Page eject before printing, single 

space after printing. 

Single space before printing, single 

space after printing. 

No space before printing, no space 
after printing. 

Any other format code will be treated like a blank but will 
not be printed. These are standard FORTRAN format char- 
acters with the exception of the minus sign (-) which is sub- 
stituted for the standard FORTRAN plus sign (+) to allow 
overprinting. The user can use M:lOEX (General I/O 
Driver) to send the standard format code or any other format 
code for XDS printers. 

Write EBCDIC to Card Punch. Regardless of the byte count 
requested, 80 bytes are always output. If fewer than 80 
bytes are requested, the punch image is filled out with 
blanks. The image is moved to a Monitor buffer; the user's 
buffer is never modified. If more than 80 bytes are re- 
quested, only the first 80 are output and the surplus is ig- 
nored. In this case, "incorrect length" status is returned. 
If the file has been declared BCD at system initialization, 
all EBCDIC output records are converted to BCD before 
being punched. (The operation is performed in the Moni- 
tor's buffer.) 

Write Binary to Card Punch. Regardless of the byte count 
requested 120 bytes are always output. If less than 
120 bytes are requested, the punch image is padded with 
trailing zeros. (The image is moved to a Monitor buffer; 
the user's buffer is never modified.) If more than 120 bytes 
are requested, only the first 120 will be output and the 
remainder ignored. In this case, an "Incorrect length" 
status is returned. 

Write EBCDIC or Binary on Magnetic Tape. Variable-length 
records are possible; no check is made of the data and no 
editing is performed. The exact byte count specified (up 
to the allowable maximum) is always written. No "incor- 
rect length" status is ever returned. 

If the tape is positioned past the end-of-tape marker and 
error checking Is specified, the data is not transmitted and 
"end-of-tape" status is returned. If error checking is not 
specified, the data Is transmitted and the "end-of-tape" 
status Is not returned. 

If the tape is physically wrlte-protected and an "initiate 
no-wait" order is requested, the "wrlte-protected" status 



blank 



No space before printing, single 
space after printing. 



For 7-track magnetic tape, the data is recorded in either 
BCD or packed-binary format, which may cause an "in- 
correct length" status if the record is not read with the same 
byte count used to write the record (see the 7-Track Mag- 
netic Tape Systems Reference Manual, Publication 90 09 78). 
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is returned. If an "initiate and wait" order is requested, 
the Monitor puts out an alarm and waits for operator action 
(see the pseudo order bytes under the definition for ORDER 
under word of the argument list). 

Write EBCDIC or Binary on Sequential RAD Files. When 
writing on blocked files, a blocking buffer must be supplied. 
If the calling program has not specified a blocking buffer, 
M:WRITE will call MrOPEN to reserve space in' the task's 
buffer pool. If no buffer is available, M:WRITE exits with 
a "blocking buffer unavailable" status. 

Records to be written on compressed files are edited with 
compression codes inserted in a Monitor buffer. The data 
in the user's buffer remains unchanged. 

For compressed files only, the logical record size has no 
meaning and the requested number of bytes is compressed 
and output. For all other files, a byte count less than, 
equal to, or greater than the logical record size can be re- 
quested and the requested number of bytes, up to the maxi- 
mum of the logical record size, is always output. If the 
byte count is greater than the logical record size, an "in- 
correct length" status is returned. In any case, the file is 
positioned to the next logical record regardless of the byte 
count transferred. 

An "end-of-tape" status is returned when the file is po- 
sitioned at the logical EOT (whether error checking is 
specified or not or If the current operation will cross the 
logical EOT). Data cannot be output past a logical EOT. 

If a Write is attempted on a file that Is either logically 
wrlte-protected or on a RAD track that Is physically write- 
protected, a "write-protected" status is returned and no 
data Is output. 

Since the RAD has no read-after-write capability as do mag- 
netic tapes, a separate Check-Write operation is essential 
to ensure absolute validity of the data output. However, 
since a separate Check-Write operation requires as much 
time as the original write operation, and the RAD has a high 
degree of reliability, the capability should only be used when 
the data is sensitive or cannot be regenerated. Backspacing 
operations must be performed before the Check-Write oper- 
ation, since no repositioning is performed at this time. For 
compressed or blocked files, no Check-Write Is allowed and 
a status of "operation not meaningful" will be returned. 



Write EBCDIC or Binary on Random-Access RAD Files. Al- 
though a granule size may be specified when a random file 
is defined, the size does not restrict the maximum number 
of bytes that may be written. However, each Write opera- 
tion begins at the start of a granule, and uncompleted gran- 
ules are filled out with zeros. The exact number of bytes 
requested is output; never with "incorrect length" status 
return. If the Write begins or extends beyond the file's 
ending boundary, no data Is transmitted and an "end-of- 
tape" status is returned, whether or not error recovery Is 
specified. The sector displacement must always be speci- 
fied; If not, a "calling sequence error" status Is returned. 



If a Write is attempted on a file that Is either logically 
write-protected or on a RAD track that Is physically write- 
protected, a write-protected status is returned and no data 
is output. 

Note: For all RAD files, no transfers will be initiated that 
will cross a track boundary. Instead, it will be 
broken Into two transfers: one to write to the end 
of the track, and a second to complete the transfer. 
Therefore, in a "no-wait" operation, a check must 
be requested to complete the transfer. If an AIO 
Receiver is specified, it will be entered each time 
channel end occurs, but it also must be specified in 
each check operation call. 

M:CTRL (General Control Routine) 

M:CTRL provides device-independent positioning capabili- 
ties for magnetic tapes (both 7-track and 9-track) and for 
sequential RAD files. All M:CTRL control functions are 
exempt from channel time limits. The calling sequence is 



LDX 

RCPYI 

B 



ADRLST 
M:CTRL 



ADRLST is the pointer to the argument list, which is a set 
of two consecutive words either in the user's program or In 
a temporary stack. This argument list appears as follows. 

word 



W 



ORDER 



12 3 15 

where 

F = 1 if this is a device-file number. 

F = if this is an operational label or device unit 
number. 

W = 1 If wait for operation is to be initiated. 

W = if no wait for operation is to be initiated 

when device/channel is busy. 

ORDER Is one of the following pseudo order bytes: 

Order Operation 

X'EB' Space Record Backward 

X'EF' Space Record Forward 

X'FB' Space File Backward 



The W flag has a different function for M:CTRL than for 
M:READ/M:WRITE. If the operation is initiated, control 
will not be restored to the calling task until the operation 
Is complete. 
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Order Operation 





X'FF' 


Space File Forward 




X'2B' 


Rewind Off Line 




X'3B' 


Rewind On Line 


word 1 








Operationo 


1 label or file number 



15 



Return is to the location in the L register. The B register is 
always saved. Status is returned in the E, A, and X regis- 
ters, as in M:READ. 

Note: For random-access RAD files, where these operations 
are not meaningful, an "operation not-meaningful" 
status will be returned. 



Space File Backward. The Space File Backward order 
positions a magnetic tope to either the start of the previous 
file mark (and EOF status is returned) or load point (if there 
Is no file mark). If the tape is already at the load point, 
the order is ignored and BOT status is returned. 

For sequential RAD files, the file is positioned to either 
the start of the logical EOF or to the logical BOT. If the 
file is positioned immediately beyond or at the logical EOF, 
it is repositioned to the point immediately before the logical 
end-of-file, and EOF status is returned. If the file is al- 
ready positioned at the logical beginning-of-tape, the order 
is ignored and BOT status is returned. If the file is blocked 
and there is output data in the blocking buffer, it is written 
on the RAD before the file is repositioned. 

Space File Forward. The Space File Forward order positions 
a magnetic tape to either the start of the next file or the 
end-of-tape mark, whichever is encountered first. Either a 
status of EOF or EOT is returned. 



M:CTRL FUNCTIONS 

If the device is a magnetic tape or a sequential RAD file, 
it is positioned as indicated. The record spacing commands 
are utilized for physical records and are not meaningful for 
FORTRAN logical records. 

Space Record Backward. The Space Record Backward order 
positions a magnetic tape to the start of the previous physi- 
cal record. If the tape is already at load point, the order 
is ignored and a BOT status is returned. If the previous rec- 
ord was either an end-of-file or end-of-tape marker, EOF 
or EOT status is returned. 

For compressed RAD files, this order is illegal and a status of 
"operation not meaningful for this device" will be returned. 

For sequential RAD files, the file is positioned to the start 
of the previous logical record. If the file is positioned at 
the logical BOT, the order is ignored and a BOT status is 
returned. If the file is positioned Immediately beyond the 
logical EOF, EOF status is returned and the file is reposi- 
tioned to the point immediately before the logical EOF. If 
the file is blocked and there is output data in the blocking 
buffer, it Iswritten on theRADbefore the file is repositioned. 

Space Record Forward. The Space Record Forward order 
positions a magnetic tape to the start of the next physical 
record. If the record skipped was either an end-of-file or 
end-of-tape marker, EOF or EOT status Is returned. 

For compressed RAD files, this order Is illegal and a 
status of "operation not meaningful for this device" will be 
returned. 

For sequential RAD files, the file Is positioned to the start 
of the next logical record. If the record skipped was the 
logical EOF, an "end-of-file" status is returned. If the 
file is positioned at the logical EOT, the record Is not 
skipped and an "end-of-tape" status Is returned. 



For sequential RAD files, the file Is positioned immediately 
at the logical EOF and "EOF" status is returned. If the 
file is already positioned beyond the logical EOF or no 
logical EOF has been written, the order is ignored and an 
"illegal RAD sequence" status is returned. If the file is 
blocked and data has been written in the blocking buffer, 
it will be written out before the file is repositioned. 

Rewind On- Line. The Rewind On- Line order rewinds mag- 
netic tape to the load point. If the tape is already at the 
load point, no error status is returned. 

For sequential RAD files, the file is positioned to the logi- 
cal BOT. If the file is already at the load point, no error 
status is returned. If the file is blocked and there is output 
data in the blocking buffer, it is written on the RAD before 
the order is executed. 

Rewind Off- Line. For magnetic tape, the tape is rewound 
and unloaded. The Rewind Off-Llne operation is useful 
for a "save" tape or for a tape at the end-of-reel when a 
new tape must be mounted. The user must control and check 
this condition. 

For sequential RAD files, the file Is closed by a call to 
M:CLOSE. If the file is blocked and there is output data 
In the blocking buffer, the data is written on the RAD be- 
fore the order is executed. In addition, the file directory 
is updated on the RAD to reflect the current position of the 
logical file mark. 



M:DATIME 



(Calendar Date and Time of Day) 



M:DATIME provides the calendar date or time of day, or 
both, to eltherforeground or background programs in EBCDIC 
format. The calling sequence is 



RCPYI 


P,L 


B 


MrDATIME 
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ADRLST is the pointer to the argument list, which is a set 
of two consecutive words either in the user's program or in 
a temporary stack. This argument list appears as follows: 

word 



D 


T 


S 





12 3 

where 

D= 1 
D = 
T = 1 
T = 
S = l 



15 



if return calendar date is specified, 
if calendar date is not required, 
if return time of day is specified, 
if time of day is not required. 



if date and time are supplied by the user (in 
Address and Address + 1). 



S - if current date or time of day, or both, are 
to be used. 



word 1 



Address 







15 



where Address is the location where the date and time of 
day are stored. 

Return is to the location in the L register. The B register is 
always saved. 

MrDATIME FUNCTIONS 

K:CLOCK in the communication region is a pointer to the 
accounting table that contains the date and time. The date 
and time are set at system initialization and can be reset by 
the operator through unsolicited key-ins. The date is auto- 
matically advanced and provisions are included for year 
changes including jieap-year adjustment. Thus, under con- 
tinuous operation, only adjustments to accommodate day- 
light savings time changes are required. The date or time 
of day, or both, are stored in the following format In the 
area of core specified by word 1 of the argument list: 



Date: 



Time: 



M 


M 


^^^^ 


D 


D 


^^^ 


Y 


Y 


A 


A 


H 


R 


M 


N 



2 blanks are sup- 
plied when both 
date and time are 
requested 



If the date and the time are supplied by the user (S = 1), 
the times supplied in Address and Address + 1 will be over- 
laid by the calendar date or time, or both. This option is 
used by the Job Control Processor ! PURGE command. 



M:TERM 



(Normal Exit from Background Programs) 



MrTERM provides an entrance back to the Monitor on a 
normal termination of a background program. The calling 
sequence is 



RCPYI 
B 



M:TERM 



M:TERM FUNCTIONS 

If called by a foreground program, control will be trans- 
ferred to M:EXIT to perform the exit sequence for that task. 
On calls from the background the L register must be set to 
a background address or the background call will be aborted 
with a protection violation. 

All I/O is allowed to run down. All files utilizing block- 
ing buffers will have their blocking buffers closed out. If 
an unconditional postmortem dump was specified, it will be 
performed at this time. The Control Command Interpreter 
will then be read into the background and will read the 
next control command. 



M:ABORT 



(Background Abort Routine) 



When a background program fails for any reason, a call to 
M:ABORT provides a method of clearing the background 
program out of core memory and for terminating all active 
I/O for the background program. The calling sequence is 



LDA 
LDX 
RCPYI 
B 



LOC 
CODE 
P,L 
M:ABORT 



Note: Time of day is given in military time (0000-2359). 



CODE is a word of EBCDIC information that is printed on 
the DO and OC devices to show why the job was aborted. 

Return is never to the location in the L register. If the call 
is from a real-time foreground program, M:EXIT is called to 
perform the exit functions. If the calling task occupies the 
nonresident foreground area, it will be disabled and an un- 
load operation will be performed. On calls from the back- 
ground, the L register must be set to the background or the 
background call will be aborted with a protection violation. 
All I/O in progress is allowed to complete and a postmortem 
dump will be performed at this time if previously requested. 
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M:SAVE 



(Interrupt Save Routine) 



M:SAVE routine performs the full context switching when 
a foreground interrupt occurs. It is available only for fore- 
ground programs that are connected directly to an interrupt. 
The calling sequence is 



RCPYI 



P,L 



MiSAVE 



the previous task, and performs the actual exit sequence. 
The calling sequence is 



RCPYI 
B 

DATA 
DATA 



P,L 

M:EXIT 
-1 
RETURN 



ADRL 



TCB 



where TCB is the address of the Task Control Block for the 
task. 

Return is to the value in the L register + 1. The contents of 
all registers except A and L are transferred to the TCB. 



Return is to the interrupted task at the address saved in the 
PSD. All registers are restored to the same value they had 
at the time of the interruption. 

If the two optional data words (DATA - 1 and DATA RETURN) 
are used, M:EXIT restores all registers and context, except 
overflow and carry and the interrupt status; but instead of 
performing the hardware exit, M:EXIT branches to RETURN. 



M:SAVE FUNCTIONS 



M:EXIT FUNCTIONS 



The contents of A and L must be saved in the proper place 
in the TCB before the task calls M:SAVE. MrSAVE then 
saves the original value of X, T, B, ahd E in the TCB. The 
interrupting task has its own floating accumulator set into 
locations 0001-0005 and the previous task's floating ac- 
cumulator pointers are saved. The M:SAVE routine stores 
the temporary stack and TCB pointers in locations 0006 and 
0007 for this current task and saves the old values in the 
interrupting task's TCB. 

If the flag In the TCB is set for "no temporary storage" 
MiSAVE saves only the hardware registers and the TCB 
pointers, and not the full context. 

If Clock 1 has been reserved for RBM accounting, M:SAVE 
will record the start time of the first interrupting foreground 
task and will trigger the RBM Control Task to calculate fore- 
ground run time. 

An additional entry point, M:FSAVE, is available for users 
of the Sigma 3 optional instruction. Store Multiple. This 
entry point, with an address literal in cell X'C7', assumes 
that all registers have been saved, but performs the remainder 
of the functions of M:SAVE as listed above. The calling 
sequence is 



RCPYI 



ADRL 



P,L 



^X'C7' 



TCB 



where TCB is the address of the Task Control Block for the 
task. 



The operations performed by M:EXIT are essentially the re- 
verse c3f those in M:SAVE. It is necessary to inhibit inter- 
rupts for about 1 1 microseconds for the actual exit sequence, 
but it is not necessary to call M:EXIT to perform the exit se- 
quence if it can be performed by the user's program. 

The TCB contains a flag to indicate whether any temporary 
storage is used. If the task does not use any Monitor I/O 
routines or the floating accumulator, no temporary storage 
is needed. In this case, only the hardware registers are 
restored. 



M:HEXIN 



(Hexadecimal to Integer Conversion) 



The MrHEXIN routine converts a hexadecimal number (rep- 
resented in EBCDIC) to a binary integer. The calling 
sequence is 



LDA 


left 


RCPY 


A,E 


LDA 


right 


RCPYI 


P,L 


B 


M:HEXIN 



where left and right contain the EBCDIC codes for the hexa- 
decimal number (the left and right part of a possible four- 
byte field). 

Return is to the location in the L register. The result is in 
the A register, the X register is changed, and the B register 
is unchanged. 



M:EXIT (Interrupt Restore Routine) 

MrEXIT restores the contents of all registers prior to exit 
from a foreground task, switches the full context back to 



M:HEXIN FUNCTION 

Blanks and zeros are treated as hexadecimal zeros. No tem- 
porary storage is used and no error checking is performed. 
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MilNHEX 



(Integer to Hexadecimal Conversion) 



The M:IN HEX routine converts a binary integer to a hexa- 
decimal representation in EBCDIC code. The calling se- 
quence is 



LDA 


integer 


RCPYI 


P,L 


B 


M:INHEX 



P - 1 if checkpoint Is to be performed at the level 

of the calling task (meaningful only If C = 1). 

P = If checkpoint is to be performed at the level 
of the RBM Control Task (meaningful only if C = 1). 



word 1 



Checkpoint Complete Receiver 



15 



where Integer is the value to be converted. 

Return Is to the location in the L register. On return, the 
E register contains the leftmost two bytes, and the A regis- 
ter contains the rightmost two bytes. The X register Is 
changed, but the B register Is unchanged. 



M:INHEX FUNCTION 

Four fields of four-bit hexadecimal codes are converted to 
four fields of eight-bit EBCDIC equivalents. No temporary 
storage Is used. 



The Checkpoint Complete Receiver should be used like an 
AIO Receiver. That Is, after requesting a checkpoint, the 
foreground program should release control by a call to 
M:EXIT and regain control through the specified receiver 
address when the checkpoint operation is completed. Only 
a foreground program can checkpoint the background; a 
background program cannot checkpoint the background area. 

Return Is always to the location contained In the L register. 
The B register Is always saved. The A register contains the 
status (1 if operation Is Impossible; If successful). 



MrCKREST FUNCTIONS 



M:CKREST (Checkpoint/Restart Background) 

M:CKREST checkpoints the background (I.e., writes it out 
onto a predefined area on the RAD), turns the background 
space over to the foreground program, and then restarts the 
background when requested. The colling sequence is 



LDX 

RCPYI 

B 



ADRLST 

P,L 

M:CKREST 



ADRLST is a pointer to an argument list, as follows: 



word 



C 


R 


P 





12 3 



15 



Checkpoint. All active I/O for the background Is allowed 
to complete but no error recovery is performed for this I/O 
until the background Is restarted. Peripheral devices dedi- 
cated to the background should not be repositioned. 

When all I/O has terminated, the entire background space 
Is written out onto a prespecified area of the RAD and the 
background is set "protected". If the background Is truly 
"empty" when the request is made, the checkpoint Is per- 
formed Immediately, and no RAD Is required for the check- 
pointing procedure. If a Checkpoint Complete Receiver 
was specified, it will be entered with the L register set 
to the return address and will be run at the RBM Control 
Task level. 

A checkpoint operation will be automatically performed 
while loading a nonresident foreground program that extends 
into the background. When the active nonresident program 
unloads (see Monitor service routine M:LOAD), the back- 
ground will be automatically restarted. When the check- 
point operation Is completed, the message ! !BKG CKPT Is 
output to inform the operator. 



where 

C =^ 1 if request is to "checkpoint" the background. 

C = If request Is to "restart" the background. 

R = 1 If a Checkpoint Complete Receiver Is to be 

Informed when the checkpoint Is complete. (Valid 
only if C = 1 and P = 0.) 

R = If no Checkpoint Complete Receiver is used. 



Restart. A restart is always performed at the priority level 
of the RBM Control Task. It is assumed that no peripherals 
have been repositioned. The core allocation table Is re- 
stored to the previous value before the checkpoint took 
place, and the background is then loaded In from the RAD 
and continues as before. 



This would occur after a IFIN command was encountered 
or when the Monitor was in an idle state after an abort of 
an attended job. 
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If no background program was in progress when the check- 
point was called for, the background is set to an unprotected 
status but no attempt is made to reload a program from the 
RAD when the foreground terminates. 

The message I ! BKG RESTART is output to inform the opera- 
tor that the background has been released by the foreground. 
See Chapter 6 for more details. 



word 1 



M:LOAD 



(Absolute Core Image Loader) 



M:LOAD initiates the loading of the root segment of a resi- 
dent or nonresident foreground program by entering the re- 
quested program name into the queue stack. It also initiates 
the loading of the root segment of a resident or nonresident 
foreground program or background processor upon request 
from the Job Control Processor. It releases (unloads) the 
nonresident foreground space for use by the next program 
in the queue. 

The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B M:LOAD 

ADRLST is a pointer to an argument list, as follows: 



DFN or CI and C2 



15 



word n 



C7 


C8 



where 



DFN 



7 8 



is the device-file number. 



15 



Cl-CB is the program name (must be 8 characters, 
including trailing blanks). 

Return is always to the location in the L register. The con- 
tents of the B register are always saved and the A register 
contains status codes, as follows: 

A Register Meaning 



Operation is successful. 

Request cannot be honored at this time 
(this could occur if Q = and a non- 
resident foreground area was already 
committed; or if Q = 1 and the queue 
stack was full). 



word 



p 


Q 


U 






12 3 



15 



where 



P = 1 indicates a request to read from the specified 

device-file number (word 1). The device-file 
number must currently be assigned to a RAD file. 
(This option is restricted for use by the Job Control 
Processor.) 

P = indicates a request to read the specified non- 
resident foreground program from the user's processor 
RAD area. The program name is given in C1-C8. 

Q = 1 indicates the request is to be queued if it 

cannot be satisfied now. 

Q = indicates the request is to be ignored if it 

cannot be satisfied now. 

U = 1 indicates an unload operation, in which case 

P and Q ore not meaningful. 

U = indicates a load operation. 



MzLOAD FUNCTION 

After savi ng the nonresident program name or device-file 
number request, M:LOAD triggers the RBM Control Subtask 
S:LOAD and then exits to the location in the L register. 

The actual loading of the program is accomplished at the pri- 
ority level of the RBM Control Task. S:LOAD will ensure 
that sufficient blocking buffers are available for those oper- 
ational labels contained in the header record of the proces- 
sor. If the request was for a nonresident foreground program 
that extends into area reserved for the background, S:LOAD 
automatically causes the background to be checkpointed. 

It is essential that each nonresident program executed in the 
nonresident foreground area terminate itself by a call to 
M:LOAD to unload, disable itself, and then exit via the 
normal interrupt exit routine (M:EXIT). This will release 
the nonresident foreground area for subsequent loads. 

For an unload request, M:LOAD triggers the RBM Control 
Task routine S:LOAD for the next load if any other entry is 
in the queue stack. If no additional requests are present 
and S:LOAD has checkpointed the background, S:LOAD 
triggers RBM Control Task S:REST for a restart. 

Note that M:LOAD inhibits interrupts for a short period 
while manipulating the queue stack (less than 100 |Jsec if no 
more than eight entries are waiting in the queue). 
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M:OPEN 



(RAD File Open) 



A Register Meaning 



M:OPEN reserves a blocking buffer from a buffer pool or a 
specified location, for o sequential blocked RAD file to 
which an operational label or device unit number had pre- 
viously been assigned. 

The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B M:OPEN 

ADRLST is a pointer to the three-word argument list shown 
below. 

word 



F B 



1 2 



15 



where 



F = 1 if a device-file number (DFN) is specified 

(internal Monitor calls only). 

F = if an operational label or device unit num- 
ber is specified. 

B = 1 if a blocking buffer location is included in 

this call. 

B = if no blocking buffer location is included, 
in which case MrOPEN attempts to find space in 
the task's buffer pool. 



word 1 



Operational label, device unit number, or DFN 



2 No space available in buffer pool. 

3 Illegal operational label or operational 
label unassigned. 

4 Not RAD file, or not a blocked RAD file. 

5 Blocking buffer outside of background 
for a file assigned to the background. 

6 Illegal DFN. 

MrOPEN FUNCTION 

The address of the blocking buffer (either the one specified 
or one located from the task's buffer pool established by an 
ABS or $BLOCK command) is stored in the File Control 
Table. If no open request has been performed for a sequen- 
tial blocked file by the user's program, M:READ, M:WRITE, 
or M:CTRL will call M.-OPEN to allocate a buffer from the 
blocking buffer pool on the first data transfer operation. 



M:CLOSE 



(RAD File Release) 



M:CLOSE releases a RAD file (including the blocking buf- 
fer if any) or releases the blocking buffer for a blocked file, 
but retains the file assignment. In either case, partially 
filled blocking buffers are written onto the RAD. The call- 
ing sequence is 



LDX 

RCPYI 

B 



ADRLST 
MrCLOSE 



ADRLST is a pointer to the argument list, as follows: 
word 





R 


B 






15 



12 3 



15 



word 2 



Address of blocking buffer (optional) 



15 



Return is to the location in the L register. The B register 
is restored. The following status information is contained 
in the A register on return. 

A Register Meaning 

Operation successful-. 

1 Blocking buffer already defined. 



where 

F = 1 if a device-file number is specified. 

F = if an operational label or device unit number 
is specified. 

R = 1 if the device-file number is to be released. 

R = if the device-file number and operational 
label remain assigned but the blocking buffer is 
to be released (the file is not to be repositioned). 

B = 1 is a buffer is specified. 

B = if no buffer is specified. 
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word 1 



Operational label, device unit number, or DFN 



15 



word 2 



Buffer location (optional) 



15 



Return is always to the location in the L register. The 
B register is always restored to its former value. The A reg- 
ister contains the following completion status. 



A Register Meaning 

Successful. 

1 Illegal DFN. 

2 The operational label is not assigned 
to a RAD file. 

3 Illegal operational label. 

4 I/O error writing blocking buffer or 
EOF onto RAD. 

5 No buffer available to complete the 
close operation. 

M:CLOSE FUNCTIONS 

If the file is blocked and data has been written on it, the 
contents of the blocking buffer are written onto the RAD. 

If the blocking buffer was allocated from the task's buffer 
pool, the buffer Is released. The EOF is written on the RAD. 

If R = 1, F = 0, and the operational label has a permanent 
assignment, the label is set "unassigned". If the label has 
no permanent assignment, the label is deleted from the table 
of operational labels. 

If an EOF has been written on the file (sequential file only 
it must also be v/ritten onto the RAD. To accomplish the 
writing, M:CLOSE requires a buffer, one sector in length, 
into which the file dictionary is read. If no buffer is speci- 
fied, M:C LOSE attempts to allocate a buffer from the task's 
buffer pool (or will use the one already opened for this file 
if it is blocked). If no buffer is available and an EOF is to 
be written, the file is not closed and an error completion 
code is returned. 



MtDKEYS 



(Read Data Keys Routine) 



M:DKEYS provides a means for background programs to read 
the data keys on the processor Control Panel. The calling 
sequence is 



RCPYI 
B 



P,L 
MrDKEYS 



Return is to the location in the L register. The contents of 
the B register are always saved. The contents of the data 
keys are in the A register on return. 



M:WAIT 



(Simulated Wait Instruction) 



M:WAIT provides a means for background programs to exe- 
cute a Wait instruction from nonprotected memory. The 
calling sequence is 



RCPYI 
B 



M:WAIT 



The return is to the location in the L register. The B regis- 
ter is always saved. The return does not take place until 
the operator performs an unsolicited S key-in. 

The Monitor types out the message 

!! BEGIN WAIT 
and goes into a wait loop. 

Only a background program may use MrWAIT; a call from 
a foreground program results in a no-operation. 

M:SEGLD (Load Overlay Segments) 

MrSEGLD loads and/or executes an overlay segment, for 
either the foreground or background, from a file previously 
prepared and saved on the RAD by the Overlay Loader or 
the Absolute Loader. 

The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B MrSEGLD 

ADRLST is a pointer to the argument list. 

word 



W 


L 


R 





Segment ID 



12 3 



7 8 



15 



where 



W - 1 if an unconditional wait for completion is 

specified. 

W = if loading is to be initiated only; control 
will be returned to the calling program. 
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L = 1 control is to be transferred to the transfer 
address of the segment just loaded (valid only 
ifW=l). 

L = control is to be returned to the calling 
program. 

R =^ 1 there is a "loading complete" receiver 
(meaningful only if W = 0). 

R = no "loading complete" receiver. 

word 1 



Operational label 



15 



The operational label is used to control the loading of the 
segment. The file must previously have been defined as a 
RAD file and set to the proper overlay program on the RAD. 
Background programs should use operational label PI. 

word 2 



ADRL of OV:LOAD 



15 



The symbol OV:LOAD must be declared as an external 
reference and is set by the Overlay Loader to the value of 
the Overlay Loader Control Table address in core. 

If the program is assembled in absolute form, the Absolute 
Loader will create the OV:LOAD table at the end of the 
root. Therefore the last item in the root would normally be 
an OV: LOAD EQU $. 



B register is always saved. On the return, the A register 
contains status showing the completion code, as follows: 

A Register Meaning 

Operation complete and successful. 

-1 Irrecoverable I/O error. 

2 Invalid call. 



MiSEGLD FUNCTIONS 

A core table of 5n+ 1 words is maintained at the end of the 
user's root segment that defines the actual RAD addresses 
for the overlay segments. (OV:LOAD points to this table; 
n is the number of segments in the program.) The segments 
may be loaded in any order because of the random-access 
capability of the RAD. Using the Loading Complete Re- 
ceiver and associated procedures can achieve greater effi- 
ciency in foreground loading. 



M:DEFiNE 



(RAD File Definition) 



M:DEFINE allocates a portion of the background temporary 
file area on the RAD for temporary use by the designated 
operational label or device unit number. This call is 
applicable to foreground operations only if the file is 
previously assigned to a permanent RAD file. The calling 
sequence is 

LDA PTR (FORTRAN programs only) 

LDX ADRLST 

RCPYI P,L 

B M:DEFINE 



word 3 



Loading Complete Receiver 



15 



PTR is the absolute address of the FORTRAN Associated 
Variable. It is meaningful only if K = 1. 

ADRLST Is a pointer to a four-word argument list. 



The Loading Complete Receiver is permissible only for fore- 
ground programs and should be used in the same way as an 
AIO Receiver. That is, after loading is initiated the fore- 
ground program should release control by a call to M:EXIT 
and regain control through the specified receiver address 
when the overlay operation is completed. 

On all calls specifying an"initiate only", a check operation 
must be performed on the operational label designated to de- 
termine the status of the load and to release the associated 
device-file number for subsequent use. 

On entry, return is to the location in the L register if the 
L parameter in word of the calling sequence is"0"; other- 
wise, control is returned to the newly loaded segment. The 



word 



F 


WP 





K 


G 






2 3 4 5 



9 10 



File Format Byte 



where 



15 



specifies the file format as follows: 

000 blocked 

001 compressed 
010 unblocked 
110 random 
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WP =11 If RBM write protection is specified. 

WP =10 if foreground write protection is specified. 

WP = 01 if background write protection is specified. 

WP = 00 if write protection is not desired. 

K = 1 if the A register contains the address of the 

FORTRAN Associated Variable. 

K = if FORTRAN Associated Variable is not 
specified. 

G = 1 if a granule size for random files Is specified; 
otherwise, the granule size is determined by the 
sector size of the reference device (meaningful 
only If F= 110). 



word 1 



Operational label or device unit number 





where 

operational labels are EBCDIC 
device unit numbers ore binary 

word 2 



15 



Number of logical records in file 



15 



word 3 



Logical record size, or granule size if G=l (bytes) 



15 



The number of logical records in the file and the logical 
record size are used to calculate the actual temp space 
required. For compressed EBCDIC files, n card images can 
normally be accommodated by n/3 80-byte records. Thus, 
12,000 card images would require 4000 80-byte records 
(about 83 tracks on a 360-byte per sector RAD). For 
blocked, uncompressed files, the total area In sectors equals 
the number of records requested, divided by the number of 
logical records per sector. Thus, 120-byte binary card 
images can be placed three per sector on a 360-byte-per- 
sector RAD. A 300-card deck would therefore require 
100 RAD sectors (seven tracks). If G = 1 and F = 1 10, the 
file size is computed using the granule size in word 3. 

If this is a random file and G = 0, then the logical record 
size is actually the FORTRAN random I/O logical record 
size and the granule size Is equal to either the physical 



sector size for temporary files, or to the granule size defined 
at file ADD time for permanent files. 

For unblocked records, the total area In sectors equals the 
number of records requested multiplied by the number of 
sectors required for each record. 

Return Is to the location in the L register. The B register Is 
restored. The A register contains status Information on the 
return, as follows: 

A Register Meaning 

Operation successful. 

1 Calling sequence error. Logical record 
size is not an even number or records 
requested. 

2 Operational label invalid (foreground) 
or no spare entry In operational label 
table. 

3 No more device -file numbers for the 
RAD. 

4 RAD overflow (files too large). 

5 If K = 1, attempted to define pre- 
viously defined file using Inconsistent 
parameters. 



MrDEFINE FUNCTIONS 

For the specified temporary file, the appropriate size is 
allocated from the pool of temporary file space if such space 
is available. An unused device-file number is then Initial- 
ized with the boundary points of this RAD file. All subse- 
quent references to this file (until closed by a call to 
M:TERM, MiABORT, or M:CLOSE) will refer to the allo- 
cated area. The file Is set to the "rewound" condition, if 
it is a sequential file. 

If the operational label is already assigned, no error status 
Is returned If it is assigned to a background RAD file. If 
K = 1, the address of the FORTRAN Associated Variable 
from the call must be the same as the one for the file. 

Note: M:DEFINE uses locations 1-3 (of the calling pro- 
gram's floating accumulator) for temporary storage. 



M:ASSIGN 



(Assign RAD Files) 



M:ASSIGN performs equivalence between an operational 
label or FORTRAN device unit number, and 

1. A RAD area. 

2. A file name within a RAD area. 

3. A device-file number. 

4. Another operational label or device unit number. 
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The calling sequence is 
LDX ADRLST 

RCPYI P,L 

B MiASSIGN 



ADRLST is a pointer to an argument list of two to eight 
words, as follows: 



word 1 



word 



TY 


F 


A 





D 



12 3 4 



12 13 



15 



where 



TY - 00 if the label is to be assigned to another 
label. 

TY = 01 if the label is to be assigned to a device- 

file number. 

TY = 10 if the label is to be assigned to a RAD 



TY - n if the label is to be assigned to a file 

within a RAD area. 

F = if the label is o background operational label. 

F = 1 if the label is a foreground operational label. 

A = 1 if the two-letter area mnemonic is contained 

in word 3; otherwise, D will specify the area. If 
A is set, D will be ignored. A must always be set 
for areas other than SP, SD, SL, UP, UD, UL, BT, 
and CP. 

D = directory to be used: 

000 Checkpoint area (area only) 

001 System Processor area 
010 System Library area 
Oil System Data area 

100 Background Temp area (area only) 

101 User Processor area 

1 10 User Library area 

1 1 1 User Data area 

No named files may exist in either the Checkpoint or Back- 
ground Temp areas. D is ignored for TY = 00 or 01 . 



oplb(l) 



15 



where opib (1) is the operational label or device unit to be 
assigned. 

word 2 



opbl (2), DFN, or buffer address 



15 



where 



opIb (2) if present, indicates that opIb (1) will be 

assigned to the device-file number that opIb (2) is 
currently assigned to. 

DFN if present, is the device-file number that 

opIb (1) will be assigned to. 

buffer address is the first word address of a buffer 
(equal to one blocking buffer in length) that will 
be used by MrASSIGN as temporary storage for the 
appropriate RAD area dictionary. This is mean- 
ingful only for TY = 11. 



word 3 



CI or Al 


C2 or A2 



7 8 



15 



If A (of first word of argument list) = 1, word 3 contains 
the two-letter area mnemonic, Al and A2; otherwise, 
word 3 contains the first two characters of the file name, 
as continued below: 

word 3 + A 



CI 


C2 



7 8 



15 



word 6 + A 



C7 


C8 



7 8 



15 



C1-C8, if present, is the name of the file to which opIb (1) 
is to be assigned. That is, this file on the RAD Is to be 
linked to an unassigned RAD device-file number to which 
opIb (1) is, in turn, assigned. This is meaningful only for 
TY= 11. 
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Return is to the location in the L register. The B register is 
restored. The A register contains status information on the 
return as follows: 

A register Meaning 

Successful operation. 

1 Mixed opibs or device-file numbers 
(foreground to background or vice 
versa). 

2 Invalid opib (2) or DFN. 

3 No spare entries in opIb or DFN tables. 

4 File name not found in designated, 
directory. 

5 RAD area not allocated. 

6 Illegitimate RAD file format. 

When the A register - 0, the X register will contain the 
standard record size of this device. 

MrASSIGN FUNCTIONS 

M:ASSIGN may be called to make any of four types of 
assignments, according to the setting of TY, as follows: 

TY = 00 opIb (1) is assigned to the DFN to which 
opIb (2) is currently assigned. OpIb (2) must be 
the same mode (foreground or background) as 
opIb (1) (error return A = 1). A background pro- 
gram cannot assign foreground opibs (error return 
A = l). 

TY == 01 opIb (1) is assigned to the specified DFN. 

DFN must be legal, must not be a RAD DFN, and 
may not be foreground if opIb (1) is background. 

TY = lOor 11 opIb (1) is assigned to a currently 

unused RAD DFN, which in turn is linked via the 
RAD dictionaries to a file on the RAD. This RAD 
file may be either an entire RAD area (e.g., sys- 
tem processor) for TY = 10, or an individual file 
within an area (e.g., XSYMBOL) for TY = 11. 
The RAD area must have been allocated at SYSGEN 
(error return A = 5). The buffer address (TY = 1 1 
only) must be in the background if the calling pro- 
gram is a background program. 

If there ore no errors, the assign will take place regardless 
of the prior status of opIb (1). For TY = 10 and 1 1, sequen- 
tial RAD files are rewound (file pointer is set to BOT). For 
TY = 00 and 01, the file position is unchanged. 



temporary area being allocated. The calling sequence for 
dynamic allocation of storage is 



M:RES 



(Temporary Storage Allocation Without Transfer) 



RCPYI 


PJ 


B 


*$ + 3 


DATA 


n 


DATA 





ADRL 


M:RES 



where n is the number of cells to be reserved. 

T must point to the background if it is a background 
program. 



A TS abort will occur if more temporary storage is requested 
than is available. 



The calling sequence for nondynamic allocation of storage 
is 

RCPYI P,T 

B *$ + 3 

DATA n 

ADRL TEMP 

ADRL M:RES 

where TEMP is the address of n reserved locations at the end 
of the calling program. This area must not contain any code 
or literals. 

Upon return, the B register contains the pointer to the new 
temporary storage stack. Locations and 1 relative to the 
base register are used by the storage allocation routines and 
may not be used by other routines. Location 2 relative to 
the base (the return address for M:POP) is set to M:ABORT. 

The calling program can set up its own exit through M:POP 
via the following. 

LDA -RETURN 

STA 2,,1 

The L and X registers are unaffected. 



M:POP 



(Temporary Storage Release Routine) 



M:RES allocates storage in a temporary stack, saves the 
previous value of B, and sets B to the first word address of 



A call to M:POP is made to release the current TEMP stor- 
age stack (pointed to by the current value in the B register), 
restore the previous value to B, and return to the location 
specified in TEMP + 2. 
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If the temporary storage was allocated by M:RES, the call 
must set up a return in TEMP + 2. The calling sequence is 



LDA 


= RETURN 


STA 


2,,1 


B 


M:POP 



where RETURN is the location to which return will be made 
after the stack is released. 

Return is to the address specified in location 2, relative to 
the beginning of the stack being released. The location in 
the L register and the return address must be in the back- 
ground area if return is to a background program. On re- 
turn, B contains its previous value before the RES-POP 
sequence. Assume return is mode to location R; L is set to 
the value R+1. 



M:OPFILE (Convert Operational Label to Device-File 

Number) 

M:OPFILE determines the file to which a foreground or 
background operational label is assigned. The calling 
sequence is 



LDA 
LDX 
RCPYI 



TYPE 
ADRLST 

M:OPFILE 



where 



TYPE is the mode of the operational label; nega- 
tive for foreground, positive for background. 

ADRLST is a pointer to the operational label. 

Return Is to the location in the L register. The B register 
is saved and restored. The status is contained in the E reg- 
ister as follows: 

E = negative if label is not found 
E = positive if label is found 

If E is positive, the following information is provided. 

Register Contents 

Device-file number 



X 

E 

A Operational label table entry 

Note; This routine is used primarily by the RBM and certain 



t 



lOCT entry address 

Operational label t( 

is used primari ly by tl 
processors. It wi 1 1 seldom be needed by user programs. 



See the chapter on SYSGEN for a discussion of the I/O 
Control Table and the Operational Label Table. 



M:RSVP (Reserve or Release Peripherals) 

MiRSVP reserves a peripheral device for foreground use 
only, until the foreground voluntarily releases the device. 



LDX 


ADRLST 


RCPYI 


P,L 


B 


M:RSVP 



ADRLST is the pointer to the argument list, which consists 
of three consecutive words either in the user's program or 
in a temporary stack. This argument list appears as follows: 

word 



F 


U 


R 


T 




Device number 



12 3 4 



15 



where 



F = 1 if request Is "reserve for foreground" . 

F = if request Is "release to background". 

U = 1 if request is for an unconditional reserve, 

where operator intervention Is not required, 

U = If request is for a conditional reserve, where 

operator intervention is required. 

R = 1 If a receiver is to be entered when the con- 

ditional reserve is completed (only meaningful if 
U-0). 

R = if no such receiver is to be used. 

T = if a device type is not specified. 

T = 1 If a device type is specified (used to distin- 



guish KP40 from PT40). 



word 1 



Reserve Complete Receiver (optional) 



15 



A Reserve Complete Receiver should be used like an AIO 
Receiver; namely, after the request has been acknowledged, 
the foreground program should release control by a call to 
M:EXIT and should regain control when the reserve has 
been effected through the specified receiver address. This 
receiver Is entered at the priority level of the RBM Control 
Task and should return to the location contained In the 
L register. If R = 0, word 1 contains the device type (see 
word 2). 

word 2 



Device type (e.g., KP) (optional) 



15 
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Return is always to the location contained in the L register. 
The A register contains status as follows: 

A = if the request is acknowledged. If F = 1 
and U = 1 (i.e., unconditional reserve), the de- 
vice is reserved for foreground use. If F = (i. e. , 
release), the device has been released for back- 
ground use. 

A = 1 if the request Is acknowledged but operator 

intervention is required. If a Reserve Complete 
Receiver is specified. It is entered when the oper- 
ator effects the reserve. This is the normal re- 
sponse to a conditional request to reserve a 
peripheral device (F = 1, U = 0). 

A = 2 if the device is not associated with a back- 

ground file. 

A = -1 if the request cannot be honored because a 

prior request to reserve this device has been made, 
if the request is to release an unreserved device, 
or If the reserve peripheral table (RSVTBL) is full. 
(See "Limitations" below.) 

MrRSVP FUNCTIONS 



message because a lower priority task has control of the file. 
M:DOW allows the use of an active file for the purpose of 
outputting alarms. The calling sequence Is 



LDX 

RCPYI 

B 



ADRLST 

PA 

M:DOW 



ADRLST Is a pointer to the four-word argument list as 
shown below: 



word 



I 15 

where 

F = 1 If a device file number Is specified. 

F = if an operational label or device unit number 
is specified. 



Reserve. If the request is for an unconditional reserve, a 
message is output to inform the operator of the foreground 
reserve action (e.g., !1FG RESERVE, LP02). 

If the request Is for a conditional reserve, a message is out- 
put to inform the operator of the request (e.g., IIFG 
REQUEST, CR03). The operator should then prepare that 
device for the pending foreground operation, and then re- 
serve the device by an unsolicited key-in of FR (foreground 
reserve; for example, FR CR03). This will reserve the de- 
vice for foreground use. A message is now output to acknow- 
ledge the reserve action (e. g. , ! I FG RESERVE, CR03). If 
the Reserve Complete Receiver is specified. It will be 
entered at this point. 



Release. The peripheral device can be released for back- 
ground use by a call to MrRSVP to release the device. The 
peripheral device specified will now be available for back- 
ground use. A message will be output to inform the operator 
of the release action (e.g., II BK RELEASE, CR03). The 
peripheral device can also be released by an unsolicited 
key-In of BR (background release). Unsolicited key-Ins to 
reserve and release peripheral devices are described in 
Chapter 3. 



word 1 



word 2 



word 3 



Operational label or file number 



15 



Address of buffer containing data 



15 



Number of b/tes to transmit 



15 



Return is to the location in the L register. The B reg- 
ister is always saved. The status is returned in the E, 
A, and X registers. The method of returning and the 
status returned are the same as described under M:READ/ 
M:WRITE. 



Limitations. The reserve peripheral table will accommo- 
date five requests at a time, which is felt to be a realistic 
limitation. 



M:DOW 



(Diagnostic Output Writer) 



Currently, multitask use of the same file may result In a 
conflict situation whereby a task is unable to output a 



M:DOW FUNCTIONS 

If the file to be used is currently active, M:DOW will 
wait until end-action-pending and will then clear the 
active file and the end-actlon-pending flags. The call 
will be translated to an equivalent call to MrWRITE which 
will output the alarm. The buffer data are assumed to 
be EBCDIC. 
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M:COC (Character-Oriented Communications) 

M:COC performs input, output, and control operations on 
a specific communication line. The calling sequence is 

LDX ADRLST Pointer to the argument list 

RCPYI P,L Set the return address 

B M:COC Branch to the routine 

ADRLST is a pointer to the argument list, as follows: 



communication will be handled on this line until 
it is disconnected, and it has the following form: 



word 




Order 


word 1 


E 


Line number 


Prompt character 


word 2 


Buffer address 


word 3 




Byte count 


word 4 


End-of-message receiver 



1 



78 



11 12 



15 



where 

Order (bits 12-15) is as follows: 

Order Operation 

Check status of line 

1 Write n bytes, no editing 

2 Read n bytes, no editing 

3 Send break character (long-space) 

4 Check previous read or write 

5 Write message of up to n bytes, edited 

6 Read message of up to n bytes, edited 

7 Disconnect line (turn off data set) 

8 Connect line 

E is 1 if an end-of-message (EOM) receiver is 
specified; is if no EOM receiver is specified. 

Prompt character is meaningful for orders 6 and 8. 
For order 6, it is the character (EBCDIC) to be 
output before input is requested. This can be used 
to signal the operator that input can now begin. 
For order 8, it specifies the mode in which all 



Bit 
8 



Vail 



M 



10 







11-12 00 
01 
10 

n 



< n < 255. 



eaning 

Echo all input characters. 
Do not echo. 

Translate all input from 7-bit 
ANSCII to EBCDIC, and all 
output from EBCDIC to ANSCII. 

Do not translate any codes. 

Check parity on input and create 
parity on output (even parity). 

Ignore parity 

Device is Model 33/35 teletype. 

Device is Model 37 teletype. 

Device is keyboard/display. 

Device is foreign device, and no 
editing or translation will be 
performed (overrides setting of 
bits 9 and 10). 



EOM receiver is used like an AIO receiver. When 
an input or output message is completed, the ap- 
propriate communications task will branch to the 
specified EOM receiver address, at the priority 
level of either the input or output external inter- 
rupt, and will show the line number (of the line 
with the completed message) in the X register. 
The user program should save this status, trigger 
an appropriate user interrupt level, and return to 
the location in the L register. All operations are 
no-waitoperations; that is, the return is immediate 
upon initiating I/O or performing the connect or 
status checks. Thus, the EOM receiver is applica- 
ble only for read (2 and 6), write (1 and 5), and 
send break (3) orders. EOM receivers are subject 
to the same restrictions and precautions as are AIO 
receivers. (See Chapter 5 for a more detailed 
discussion of AIO receivers.) 

Return is to the location specified in the L register. On re- 
turn, the B register remains unchanged; and the E, A, and 
X registers are set as specified in Tables 11, 12, 13, and 14. 

The nine possible orders that can appear in the argument 
list, and the operation for each, are described below: 

Check status of line. This operation allows the 
user to check both the logical condition of the line 
(which must be one of the unique codes in Table 14) 
and the physical condition of the line (which is 
reported just as it is received from the hardware). 
Onlythe line number is needed in the argument list. 
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Table 1 1. Status Returns for M:COC 



Operation 


Major Status 


Action 


E 


A 


X 


All operations 


Line no. not valid 


Return 
immediately 


-1 


8 


Line no. 


Calling seq. err. 


-1 


4 


Line no. 


Line has disconnected 


-1 


2 


Line no. 


Invalid line status 


-1 


1 


Line no. 


Initiate read 
or write 


Line is busy 


Return 
immediately 





-1 


Line no. 


Successfully initiated 


Initiate and 
return 








Line no. 


Check previous 
input or output 


Line is busy 


Return 
immediately 





-1 


Line no. 


Operation complete 


Return 





Completion 
code 


Byte count 


Connect or 
disconnect 


Successful connection 


Connect and 
return 








Line no. 


Check status 


Connected line 


Test and 
return 


Line 
status 


Line mode 


Line no. 



Table 12. Completion Codes 



A Register Value 



Ml 



eoning 



Successful completion 

Parity error on some byte read 

Break condition exists 



Table 13. Line Status 



E Register Bits 



0-11 
12-13 
14-15 



Meaning 



Not used 

Receiver status (O and C bits) 

Transmitter status (O and C bits) 



Table 14. Line Mode 



A Register Value 


Meaning 





Line is disconnected 


1 


Output mode 


2 


Output prompt character and then 




switch to input 


3 


Input mode 


4 


Inactive mode 


5 


Message complete 



Write n bytes^ no editing. If the byte count is 
odd, the first output transmission takes place 
from right of the first v/ord, and the left of the 
first word is ignored. No end-of-message codes 
are added at the end of the message, and no 
trailing blanks or null characters are stripped 
off. Parity generation and translation from EBCDIC 
to ANSCII are under the control of the specified 
options for this line. 



Read n bytes, no editing. A read operation is 
initiated, with no editing for cancel or character- 
delete operations, but with a search for any 
ANSCII control character. Input is terminated 
if any control character is found or if the speci- 
fied byte count is exhausted. If any input bytes 
were received before this read request was given, 
these bytes are thrown away. The end-of-message 
character always remains in the user's input buf- 
fer, translated to EBCDIC, if specified. The 
same comments about parity apply for the write 
operations. 



Send break character (long-space). If the line is 
in an inactive mode, the long-space is sent imme- 
diately. If the line is in a write mode or a read 
mode, the operation is terminated and the long- 
space is then sent. In the argument list, only the 
line number is meaningful. 
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Check previous read or write. This operation is 
required for all read and write operations, whether 
or not an EOM receiver is specified. The user 
buffer remains busy until the previous operation is 
checked. The line is then set inactive and becomes 
ready for subsequent use. This is the only way to 
determine break conditions. The return status is 
shown in Tables 1 1 and 12. Only the line number 
is meaningful in the argument list. 



7 Disconnect line. The data set is disconnected, but 
the send and receive modules remain connected. 
The logical line mode is cleared (i. e. , disconnected). 

8 Connect line. The logical line mode is set to 
"inactive" and the options are initialized. The 
connect line is assumed to be a dedicated line or 
a line that has already dialed-in, A user program 
can poll the lines with a "check status" order to 
determine when a line has connected. 



Write message of up to n bytes, edited. This op- 
erates like the write operation without editing 
except (1) that trailing blanks and trailing null 
characters are removed and (2) that appropriate 
control characters are added as the final charac- 
ters of the message. 



Read message of up to n bytes, edited. This oper- 
ates like the read without editing, except that 
ignore, backspace, and cancel operations are in 
effect for the current line; when any of these 
special characters are encountered, the proper 
effect takes place on the line and the user's buffer 
is modified accordingly. (Note that the backspace 
is an editing, or destructive, backspace; that is, the 
previous character is deleted from the user's buf- 
fer.) The prompt character, if nonzero, is output 
prior to the read operation. (See Table 15 for a 
summary of editing operations.) 



M:COC FUNCTION 

Once the RCOC initialization routine has prepared the 
communication equipment, the status of each line is "dis- 
connected". All input and output are rejected until the 
line Is connected. If the line is dedicated, only a "con- 
nect line" call to M:COC is required. If the line must be 
dialed-in (using M:IOEX), the dial operation must precede 
the "connect line" coll to M:COC. The connect sets the 
line status to "inactive" (I.e. , available for I/O transfers). 
I/O operations are initialized sequentially, and when com- 
pleted, the line status is set to "message complete". At 
this point the line Is still busy and can be cleared (i.e., 
set to "Inactive") only by a call to M:COC to check the 
status of the previous operation (order 4). The call "check 
operation" is not required after a check status, a connect 
or a disconnect operation. A disconnect operation sets the 
line status to "disconnected", and the line must be recon- 
nected before it can be used again (see Appendix F). 



Table 15. Summary of Editing Operations 



Operation 


Codes Used 










33/35 


37 


Character Display 


User-generated end-of-message 


CR or LF or BREAK 


NL or BREAK 


NLor INTERRUPT 


character on input, edited 








System-generated end-of- 


LF or CR (opposite of 


None for NL; 


None for NL; NL for INTERRUPT 


message character on input 


user input); 

CR and LF on BREAK 


NL for BREAK 




Attention code; used to 


BREAK 


BREAK 


INTERRUPT 


terminate input or output 








Ignore this character, except 


RUBOUT or 


DEL or 


DEL or 


after ESC 


ESC,SPACE 


ESC, SPACE 


ESC, SPACE 


System-generated characters 


CR,LF,RUBOUT 


NL, RUBOUT 


NL,5- NULL 


on output at end-of-message 








Delete previous character 


ESC,RUBOUT 


ESC,DELETE 


ESC,DELETE or EM 




(echo- — ) 


(echo\) 


operation 


Delete current line 


ESC,X 


ESC,X 


ESC,XorCR,CAN 
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5. I/O OPERATIONS 



BYTE-ORIENTED SYSTEM 

The Monif-or performs all I/O services for the byte- 
oriented I/O system. This includes: 

Loglcal-to-physical device equivalencing. 

Initiating I/O requests. 

Standard error checking and recovery (optional). 

Software checking of background and Monitor. 

Software checking of background requests to preserve 
protection of foreground and Monitor. 

Optionally generating device order bytes for device- 
independent operations. 

Accepting user-generated lOCDs and device order 
bytes to provide complete control for a user's 
program. 

Using data chaining for foreground programs performing 
scatter-read or gather-write operations. 

Reading or punching cards in either BCD or 
EBCDIC. 

Positioning magnetic tapes and sequential RAD files. 

Editing from paper tape or keyboard/printer. 

All I/O interrupt handling. 

Managing both temporary and permanent RAD 
files. 

Limiting channel active time for ^O transfers. 

I/O INITIATION 

Whenever a task needs to initiate an I/O operation, it 
calls on the appropriate Monitor I/O routine (see Chap- 
ter 4 for complete calling sequences). These Monitor 
I/O routines are reentrant, so that a higher priority 
task may interrupt and request I/O during the initiation 
of a lower-priority task, in which cose the low-priority 
task is suspended and the higher-priority task satisfied 
first. 



The channel time limits imposed by the Monitor on standard 
devices are as follows: 

Maximum Allowable Channel 



Device Type 


Active Time (seconds) 


KP 


255 


LP 


3 


CR 


3 


CP 


3 


M9 


10 


PT 


820 


BR 


3 


BP 


3 


M7 


10 


RD 7202,7204 


3 


RD 7242 


4 


PL 


Not imposed 



END ACTION 

The chapter on Operator Communication specifies the pos- 
sible error messages. Generally, standard error recovery 
takes place when the I/O is checked for completion rather 
than on the I/O interrupt. This means that error recovery 
for the background will be processed at the priority level 
of the background rather than at the I/O interrupt priority 
level. However, there is a provision for the real-time fore- 
ground user to specify an end-action routine to be called 
when the Monitor answers the I/O interrupt. This is the 
AIO Receiver address in the I/O calling sequence, and it 
is to be used only when more sophisticated end-action is 
required or when a foreground task is to be restored to active 
status at channel end. The routine is processed at the priority 
level of the I/O interrupt, so the processing should be of 
very short duration. Reentrancy in this routine is the user's 
responsibility. For example, this routine might consist of 
storing the I/O status information and then triggering a 
lower-level external interrupt through a Write Direct, where 
this lower-level task performs the actual processing. The 
end-action routine should then return to the task from which 
it originally came (by RCPY L, P). 

The form of the call to the AIO Receiver is 



A real-time foreground program may acquire control of 
a multidevice controller from background users at the 
completion of any current I/O. This technique is used 
in,place of queuing. All Monitor I/O initiation is made 
at the priority of the calling task, with background tasks 
having the lowest priority. 



LDA 

RCPYI 

B 



AIODSB 



P,L 



AIO Receiver address 



(device status byte 
from AIO in bits 0-7; 
device number in 
bits 8-15) 
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The AIO Receiver routine should return to the location 
contained in the L register on the entry. All registers are 
assumed to be volatile, which means that they need not be 
saved and restored to their former contents. 



The purpose of the AIO Receiver technique is to al low a 
real-time user program to be informed by RBM when chan- 
nel end occurs on a particular I/O operation. ' It is used 
instead of I/O queueing by the Monitor. Typically a fore- 
ground program wishing to maximize I/O and computation 
overlap will issue an I/O request with the no-wait option 
and with an AIO Receiver address specified. When the 
I/O is successfully initiated, the foreground task exits from 
the active state (by a call to M:EXIT) and is restored to 
active status at channel end by a Write Direct to trigger 
the interrupt level from the AIO Receiver. The foreground 
program must then return to the Monitor I/O routine with 
the "check" option to complete the end action on the 
file. See Chapter 6 for a more detailed discussion of 
AIO Receivers. 



Note: For transfers invoking blocked files where no 
I/O is actually performed, the X register will 
contain -1 to indicate that the AIO receiver 
will not be entered. 



Table 16. Standard Device Unit Numbers 



Device Unit 




Number 


Standard Assignment 


101 


Keyboard/printer input 


102 


Keyboard/printer output 


103 


Paper tape reader 


104 


Paper tape punch 


105 


Card reader 


106 


Card punch 


108 


Line printer 



Table 2 shows the standard background operational labels. 
The devices and functions shown indicate how the standard 
processors use these labels. Since each I/O call must specify 
a byte count, a user program can read any number of bytes 
from SI (if SI is magnetic tape, for example). The labels 
are merely a name. There is no restriction on the record 
size except as imposed by the peripheral devices. 



LOGICAL/PHYSICAL DEVICE EQUIVALENCE 

When writing a foreground or background program in 
either Symbol or FORTRAN, the user is not required to 
know the actual physical device number that will be 
used in the input/output operation. Two ways are pro- 
vided under RBM to help the user select the input/output 
device on a logical rather than physical basis. 



The first method is the direct logical reference. The user 
can specify a device-file number in his calling parameters 
to the input/output routines, and RBM will translate this 
into an actual physical device number. There may be 
several device-file numbers pointing to the same physical 
device; however, only one device-file number is generally 
needed per device per active task in the system. Each 
device-file number can be used by only one task at a time. 
This is a necessary restriction since the I/O status is saved 
in the device-file number table in theRBMand independent 
operation by several tasks on the same device would cause 
invalid status from the separate tasks using it. 



The second method is device referencing through indirect 
logical reference. This method first assigns a device unit 
number or an operational label to a device-file number, 
which in turn is assigned to a physical device number. The 
equivalence of operational labels or device unit numbers 
and the device-file numbers is set at System Generation 
time for certain standard devices, as shown in Tables 2 
and 16. The standard assignments may be changed later by 
use of ! ASSIGN or ! DEFINE control commands. 



RAD FILES 

The two types of RAD files available are sequential files 
and random files. A sequential file may be used like a 
single-file magnetic tape, whereas a random file may be 
used like a truly direct-access device. The capabilities 
and restrictions of each type of file are described below. 



SEQUENTIAL FILES 

Sequential RAD files are available to foreground and 
background tasks. 



Sequential RAD files are available to routines M:READ, 
M:WRITE, and M:CTRL, but not to M:IOEX. 



3. Sequential RAD files can be blocked (with more than 
one logical record per sector) if the logical record size 
is less than or equal to half the RAD sector size. The 
Monitor I/O routines do the blocking and 
unblocking. 



Sequential RAD files can be compressed (with blanks 
removed) if they are EBCDIC data. The Monitor I/O 
routines do the compressing and expanding but do not 
check for binary data. Compressed records are always 
blocked and of variable size; therefore the logical 
record size has no meaning except when allocating 
the file. 
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9. 



Logical records may be less than, equal to, or greater 
than the RAD sector size. Unblocked records always 
start on a sector boundary. Therefore, if a logical 
record is less than a RAD sector and is unblocked, the 
remaining bytes of the sector will be ignored. If a 
logical record is greater than a sector, it will occupy 
an integral number of physical sectors and the remain- 
ing bytes of the last sector will be ignored. 



BOT (beginning-of-tape) is defined as the logical load- 
point and equals the first sector of the file. EOT is de- 
fined as the logical end-of-tape and equals the last 
sector +1 of the file. EOF (end-of-file) is defined as 
the logical file mark (which may or may not exist). 



As on magnetic tape, once a logical record or file mark 
is written on a file, any records orfilemorks previously 
written beyond that point are unpredictable. 



Sequential RAD files (except compressed files) can be 
spaced forward or backward by logical records. 



Sequential RAD files can be positioned by {REWIND, 
IFBACK, and IFSKIP commands. 



10. Sequential RAD files can request an AIO Receiver at 
channel end for physical I/O transfers. When oper- 
ations involve only logical I/O transfers, the AIO 
Receiver will be ignored. A flag will be set indicating 
whether the AIO Receiver is to be acknowledged or 
not, (see M:READ/M:WRITE status returns). 



11. RAD transfers must consist of an even number of 



bytes. 



Random files are available to routines MiREAD and 
MrWRITE, but not to M:CTRL or MrlOEX. 



All I/O transfers start on a granule boundary within 
a file. These granule boundaries are addressed as a 
number that represents the displacement of the 
granule from the start of the file, beginning with 
zero. A granule boundary always begins on a 
sector boundary but need not end on one (see dis- 
cussion of granules below). 



4. All positioning commands such as IREWIND, IFSKIP, 
IWRITE EOF, etc., are meaningless. 



The transfer of any number of bytes (up to a maximum 
of 65, 536) may be requested, provided that the byte 
count is an even number and the transfer will not ex- 
tend past the file boundary. 



6. Operational labels can be equated to permanent files 
on the RAD or can be allocated from available tem- 
porary RAD space. This can be accomplished either 
through control commands (for standard assignments) or 
through Monitor service calls at execution time for 
nonstandard assignments. 



7. When a random file is defined, the user may specify 
a FORTRAN logical record size and a pointer to the 
word where the last referenced FORTRAN logical 
record +1 is stored. This information, although un- 
used by the Monitor, is stored in the file and may be 
requested by executing programs or processors (such as 
the FORTRAN compiler), if necessary. 



12. Operational labels can be equated to permanent files 
on the RAD, or be allocated from available temporary 
RAD space. This can be accomplished either through 
control cards (for standard assignments) or through 
Monitor service calls at execution time for nonstandard 
assignments. 



13. When the operational label is defined or assigned 
to a permanent file, it is automatically positioned 
at the BOT. 



9. 



Random files cannot be blocked or compressed, unless 
the user program performs its own blocking/deblocking 
or compression/decompression. 



BOT is defined as the first sector of the file. EOT is 
defined as the last sector +1 of the file. EOF has no 
meaning in random files except for mapping purposes. 



14. As on magnetic tape, the only record that can be 
written at the EOT is the logical file mark. 



10. Requests for a foreground AIO Receiver at channel end 
will always be acknowledged. 



RANDOM FILES 

1. Random files are available to foreground and back- 
ground jobs. 



GRANULES 

Granules are the minimum physical amount of data that are 
transferred in a read or write operation from or to random 
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RAD/disk pack files. While a granule is usually synonymous 
with a sector on a device, it may be defined (on a file 
basis) to be equivalent to any of the following: 

• a partial sector 

• one sector 

• several sectors 



A granule always begins on a sector boundary but need 
not end on such a boundary. For example, to make the 
7204 RAD and the 7242 disk pack transfers equivalent, a 
granule can be defined to be 1024 bytes; this is then one 
sector on the disk pack and two sectors plus a fraction of 
a sector on the 7204 RAD. 



RAD FILE MANAGEMENT 

RBM permits allocation of the RAD into the subsections 
shown in Figure 4. The exact bounds on these sections are 
computed from the size of required contents or selected by 
the user in accordance with the anticipated use of the 
system. In either case, the bounds are set during System 
Generation, and cannot be changed except by a new 
System Generation. RBM maintains directories for as many 
areas as the user specifies up to 15, plus: the System Li- 
brary, System Processor area, and System Data area. RBM 
also maintains control of the checkpoint area. The back- 
ground temporary space is allocated from control command 
inputs or from calls to M:DEFINE as requested. 

Areas need not be allocated contiguously (RAD tracks may 
be skipped between areas), and can be distributed over 
more than one RAD. However, each area must exist en- 
tirely on a single RAD. If there is more than one RAD on 
the system, one will be designated as the RBM System RAD, 
which will receive any default areas. Any RAD with sec- 
tor available will receive a bootstrap in that area. 



RBM Bootstrap Loader 



System Processor area 



System Library area 



System Data area 

RBMGO RBMAL 

RBMOV RBMS2 

RBMPMD RBMSYM 
RBMID 



User Processor area 



User Library area 



User Data area 



Checkpoint area 



Background temporary storage 



Xn area 



Dn area 



Figure 4. RAD Allocation 
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6. REALTIME PROGRAMMING 



FOREGROUND PROGRAMS 

Under the Sigma 2/3 RBM, a foreground program is one that 
operates in protected memory, utilizes foreground opera- 
tional labels or device unit numbers, and has access to 
privileged Sigma 2/3 instructions. It is protected from any 
background interference through an integrated hardware/ 
softv^are protection scheme. A foreground program may be 
classified as either a resident foreground program, a semi- 
resident foreground program, or a nonresident foreground 
program, and it it Important that this distinction be 
understood. 



RESIDENT FOREGROUND PROGRAM 

Foreground programs are defined as resident through the 
RAD Editor when their files are created on the user pro- 
cessor area of the RAD. They are loaded into core from 
the RAD whenever the RBM system is booted, and are either 
automatically armed, enabled and (optionally) triggered, 
or they initialize themselves through their own initializa- 
tion routines. Once loaded into core for execution, resi- 
dent foreground programs remain resident until the RBM 
system is again booted from the RAD. 

SEMIRESIDENT FOREGROUND PROGRAM 

Semiresident foreground programs are normally not in core 
memory. They are not read into core when the RBM system 
is booted but must be called in explicitly when needed. 
Semiresident foreground programs, when loaded, reside in 
the resident foreground area. The user must schedule the 
loading of semiresident foreground programs because the 
Monitor provides no protection against overlay or over- 
loading. When loaded, they may be automatically armed, 
enabled and (optionally) triggered, or they may initialize 
themselves through their own initialization routines. 

NONRESIDENT FOREGROUND PROGRAMS 

Nonresident foreground programs are normally not in core 
memory. They are not read into core when the RBM system 
is booted but must be called in explicitly when needed. 
Nonresident foreground programs, when loaded, reside in 
the nonresident foreground area, and the area is then consid- 
ered "active" and is not available for subsequent use by other 
programs (including the Monitor) until the program occupying 
this area releases it by "unloading". This feature is useful 
when a system has several nonresident foreground programs 
that have a resource allocation problem or are connected to 
the same interrupt level. The Monitor will control access 
to the nonresident foreground area, thus providing protec- 
tion against multiple loading of these conflicting programs. 

If nonresident programs are to be used, at least six cells 
must be allocated for the nonresident foreground area of 
core. If allocated, the nonresident foreground area is 



adjacent to the background. If a nonresident foreground 
program is to be loaded and the length of the longest path 
(including COMMON) exceeds the size of the nonresident 
foreground area, the background is automatically check- 
pointed to allow the program to extend to the background. 
The background remains checkpointed until the nonresident 
foreground program unloads by a call to McLOAD. When 
loaded, nonresident foreground programs may be automati- 
cally armed, enabled and (optionally) triggered; or they 
may initialize themselves through their own initialization 
routines. 

MONITOR TASKS 

The relative priorities of the separate Monitor tasks are 
given in descending order below: 

Highest Counters (optional) 

Power On Task 

Power Off Task 

Memory Parity Error Task 

Protection Violation Task 

Multiply Exception Task (optional) 

Divide Exception Task (optional) 

Input/Output Task 

Control Panel Task 

Counters = (optional) 

Real-Time Task(s), if any lower than I/O 

RBM Control Task (lowest hardware level) 

Background (lower than all hardware levels) 

Although the tasks are not reentrant, they are serially 
reusable; that is, as soon as a task finishes processing one 
request, it can immediately process another. For example, 
I/O interrupts are processed one at a time, with the highest 
priority device always processed first if several interrupts 
are waiting, but as soon as the processing of one interrupt 
request has been completed, another request for a separate 
device can be processed. 

POWER ON TASK 

The Power On Task performs the following operations: 

• Waits for acceptable RAD status, 

• Loads and links and branches to power-on overlay. 
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• Disarms all external and internal interrupt levels, 
then arms and enables all interrupt levels. 

• Interrogates foreground mailbox X'C4' for a power-on 
receiver, and If one is specified, links and branches 
to it. An override task is one that services an inter- 
rupt generated at the override group level (dedicated 
interrupt locations X'100' to X'105'). The receiver for 
such a task may be specified by loading a resident task 
into foreground. This task must have a small initiali- 
zation routine that sets the corresponding foreground 
mailbox to point to the real-time portion of the re- 
ceiver. The various receiver mailbox addresses and 
their corresponding functions are as follows: 



Address 



Receiver Function 



X'C3' 


Power Off 


X'C4' 


Power On 


X'C5' 


Integral lOP Timeout 


X'C6' 


Watchdog Timeout 



• Scans the Channel Status Table and, for any active 
I/O channel, sets Unusual End and Memory Parity Error 
flags and simulates an l/O interrupt. 

• Retriggers any task that has its TCB address in the 
TCB chain. 



• Restores protection registers. 

• Triggers RBM to write the message ! ! POWER ON. 

• Reloads the overlay region. 

• Switches the dedicated interrupt location for any 
task that requires retriggering, so that the interrupt 
branches to a separate Power On Task. This separate 
Power On Task then branches to the point at which the 
task (at this interrupt level) was interrupted and subse- 
quently switches the dedicated interrupt location back 
to its proper value. 

• Exits the power failure task (i.e., the Power Off 
Task). 



POWER OFF TASK 

The Power Off Task performs the following operations: 

• Saves the internal interrupt status. 

• Saves context via a call to M:SAVE. 

• Scans the Channel Status Table and issues an HIO to 
any channel flagged active and saves the device status 
byte and the even and odd channel register contents in 
the File Control Table. 



• Saves the RAD address of the RAD that has the system 
processor (SP) area. 

• Interrogates foreground mailbox X'C3' for a power-off 
receiver. If one is specified, a branch is made to it; 
otherwise, the Power Off Task waits for the power-on 
interrupt. 



MACHINE FAULT TASK 

This task is responsible for examining memory parity errors 
and watchdog timeouts. If a memory parity error occurs 
while the background is active, the background program is 
aborted and the real-time foreground is not disturbed. The 
Machine Fault Task calls the reentrant Monitor routine 
M:ABORT which sets the flag for the S:ABORT subtask and 
triggers the RBM Control Task. S:ABORT then aborts the 
background and prints an error message. 

If a memory parity error occurs while a foreground task is 
active and if the number of foreground parity errors has not 
exceeded the specified limit, the Machine Fault Task sets 
a flag to cause the RBM Control Task to output the fol- 
lowing diagnostic: 

! !FG PARITY ERR, TCB=FFFF, LOC=FFFF, A=FFFF, 
X=FFFF, B=FFFF 

Processing continues from the point where the parity er- 
ror occurred. 

If a memory parity error occurs while a foreground task is 
active and if the number of foreground parity errors has 
exceeded the specified limit, the Machine Fault Task does 
the following: 

1. Disables the active task. 

2. Sets a flag to cause the RBM Control Task to output 
a diagnostic. 

3. Resets the foreground parity error counters. 

4. Exits and simultaneously forces the active task to 
terminate. 

The RBM Control Task outputs the following diagnostic: 

! IFG PARITY ERX, TCB=FFFF, LOC=FFFF, A=FFFF, 
X=FFFF, B=FFFF 

where ERX indicates that the task has been disabled and 
terminated. 

All tasks that do not use M:SAVE must set K:TCB correctly 
to guarantee proper recovery from a memory parity error. 

If an integral lOP watchdog timeout occurs, the Machine 
Fault Task interrogates foreground mailbox X'C5' for an 
Integral lOP timeout receiver. If a receiver Is specified, 
the Machine Fault Task links and branches to it; other- 
wise, the Machine Fault Task enters the "wait" state. The 
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overflow bit will be set, and the control panel interrupt 
will be ineffective in clearing this "wait". When this hap- 
pens, a Customer Engineer should be notified immediately. 



If an external lOP watchdog timeout occurs (usually as the 
result of attempting direct I/O to an unrecognized device), 
the Machine Fault Task interrogates foreground mailbox 
X'C6' for a receiver. If a receiver is specified, the 
Machine Fault Task branches to it; otherwise the Machine 
Fault Task outputs the message 

HMACH. FAULT; TCB-FFFF, LOC-FFFF, A=FFFF, 
X-FFFF. B^FFFF 



INPUT/OUTPUT TASK 

After an input/output interrupt, the Input/Output Task 
identifies the highest priority device with a pending 
interrupt. It then clears the channel activity status and 
sets the operational status byte count residue in the proper 
device-file status table, if the device is no longer opera- 
ting. (The channel is not cleared for a zero-byte-count 
interrupt.) If a foreground AIO Receiver was specified (for 
a description of an AIO Receiver, see "I/O Operations" in 
Chapter 5), control is transferred to this receiver at the 
I/O priority level. It is expected that the AIO Receiver 
exit properly. 



It then changes the program status to set the overflow and 
carry when it exits, and attempts to continue with the 
foreground task. If this interrupt occurs twice for the same 
task, the Machine Fault Task triggers RBM to write the 
following message: 

HMACH. FAULX; TCB-FFFF, LOC=FFFF, A^FFFF, 
X=FFFF, B=FFFF 

It then disables and terminates the current foreground tasks. 



To minimize interrupt inhibit time, the channel registers 
are loaded and the \/0 initiating SIO is issued at the I/O 
interrupt priority level. Consequently, any task with a 
priority level higher than I/O must not use M:READ, 
MrWRITE, or MiIOEX to perform I/O, but may perform 
its own I/O without interrupts. 



When Clock 1 is employed (a SYSGEN option), M:READ/ 
M:WRITE operations are subject to a time limit. Clock 1 is 
used to ensure that no channel is active beyond a preset 
limit. If the limit is exceeded, an HIO is issued to the 
offending device and appropriate end action will be taken. 



PROTECTION VIOUTION TASK 

Any attempt by the background to modify the contents of 
protected memory, or to execute a privileged instruction, 
will cause the Protection Violation Task to abort the back- 
ground program, using the same method as the Memory 
Parity Task. 

Unavailable core is set "protected". Write attempts to 
unavailable core cause protection errors, and read attempts 
from unavailable core cause parity errors. The abort code 
after a protection error shows the location causing the error 
if the error was an invalid store or a privileged instruction. 
An attempt by the background to branch to protected mem- 
ory will cause an abort with the address of the location that 
was being branched to. Note that Monitor service routine 
calls actually cause a protection violation from the back- 
ground. However, if the branch address and the return to 
the background are valid, the branch is permitted. 



Certain RAD ^O operations are subject to a minimum-seek 
algorithm. Under this algorithm, RAD seeks are not initi- 
ated until the RAD is positioned within two sectors of the 
first sector to be read. This prevents low-priority tasks from 
denying RAD access to high-priority tasks. The algorithm 
applies to all "wait" requests (see description of M:READ 
and M:WRITE in Chapter 4). 



CONTROL PANEL TASK 

A Control Panel Interrupt causes the Control Panel Task to 
set a flag for the RBM Control Task, trigger the task, and 
then exit from the Control Panel Task (about 40 to 50 micro- 
seconds of CPU time). The operator response is processed 
at the level of the RBM Control Task. 



The set multiple precision mode instruction, RD X'8T, does 
not cause a protection violation when multiple precision 
hardware is implemented. 



MULTIPLY/DIVIDE EXCEPTION TASKS 

These tasks simulate andsubsequentlyexecutea Multiply or 
Divide instruction for Sigma 2/3 computers not equipped with 
Multiply/Divide hardware. They are not reentrant, so all 
lower interrupts are locked out for the duration of the simu- 
lation (approximately 250 to 300 CPU microseconds. ) 



RBM CONTROL TASK 

This task controls unsolicited key-ins and background oper- 
ations. It is the only RBM task that actually performs input/ 
output and, therefore, is the only task that requires tempor- 
ary stack space for the reentrant RBM input/output routines. 



SCHEDULING RESIDENT FOREGROUND TASKS 

When several different programs and tasks are simulta- 
nously located in core memory, scheduling is required for 
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theorderly transfer of control from one task to another. Sched- 
uling takes place in accordance with the following rules: 

1 . When no background or foreground task is active in 
the system, the Monitor enters the "idle" state until 
the operator directs the loading of a set of control 
commands from an input device. 

2. After a background program is loaded, the Monitor 
transfers control to the program by an exit sequence 
from the RBM Control Task. During execution of the 
background program (if the program is waiting for its 
own I/O to complete), there can be nothing else in 
execution in the system. That is, the Monitor makes 
no attempt to multiprogram to absorb idle time. If 
there is an armed and enabled resident foreground task 
in core, the foreground program may receive an inter- 
rupt from some external source. 

3. After entry, the interrupting task saves the contents of 
any registers it will alter and proceeds to carry out its 
function. The task may use either the M:SAVE service 
routine to perform the saving operations or it may save 
the contents of the registers itself. 

4. When the real-time task is completed, it may restore 
the context of the interrupted task and exit via the 
standard Sigma 2/3 exit procedure or may have these 
functions performed by the M:EXIT service routine. 



Note that this is a last-in, first-out form of scheduling. 
The interrupting task may itself be interrupted at any time 
during execution by a higher priority task, up to the maxi- 
mum possible number of tasks in the system. 



Each time, a new task saves the status and register contents 
of the interrupted task. When the new task exits, control 
is returned automatically to the task it interrupted. If there 
is another interrupt waiting between the level of the current 
task (which is just completing) and the interrupted task, the 
originally interrupted task is immediately interrupted again 
and the new (intermediate) task follows the same procedure. 
Thus, it is never necessary for any task to know what task 
precedes or follows it. The task merely preserves and re- 
stores the environment according to the established rules. 



active. This task may or may not be the one that just re- 
ceived the Write Direct. Eventually, the task that re- 
ceived the Write Direct will be reached, and this task will 
then continue the processing at that level. Thus, real-time 
foreground programs can hove an intricate scheduling scheme 
with no RBM intervention. 



An example of interrupt-driven scheduling is illustrated in 
Figure 5. 



LOADING FOREGROUND PROGRAMS 

Foreground programs may be loaded into core for execution 
in any of several ways. All programs must reside on the RAD 
to be read into core memory for execution. They must be 
written onto the RAD by the Overlay Loader or the Absolute 
Loader ."^ In each of the methods described below, only the 
root is loaded into memory as a result of the action taken. 
Segments must be read in by subsequent calls to M:SEGLD. 



The most common method of loading a foreground program is 
through a call to M:LOAD by another foreground program. 
The call takes place at the priority level of the foreground 
program and the request is placed into the queue stack. The 
program isactually loaded by the Monitorsubroutine S:LOAD 
at the level of the RBM Control Task, and this method is the 
most logical one to be used. It is based upon conditions 
automatically detected by other foreground programs and 
requires no response or assistance from the operator. 



Another method of loading a foreground program is through 
an unsolicited key-in by the operator. The operator must 
generate a Control Panel Interrupt and, in response to the 
request HKEYIN, type in "Q name", where "name" must 
be the name of a foreground program residing in the user 
processor area of the RAD. This action results in a call to 
M:LOAD to queue the request. This method could be used 
in response to conditions detected outside the computer sys- 
tem (e.g., a certain time of day). Both the above methods 
apply to semiresident as well as nonresident foreground pro- 
grams. For resident foreground programs, they would be 
used only to obtain a fresh copy of a particular program 
without rebooting the entire system. 



The design of the hardware priority system makes itunneces- 
sary for the Monitor to be involved In the actual scheduling, 
and this procedure allows the task and programs to indepen- 
dently control the execution priority of certain operations 
within the foreground. For example, a real-time fore- 
ground task that is activated by an external interrupt may 
perform some processing and then issue a special Write 
Direct to trigger another related task to continue the pro- 
cessing at a higher or lower interrupt level. If the Write 
Direct is to a higher level, the interrupt to the higher level 
takes place immediately and the new task is begun. More 
frequently, the Write Direct is to a task at a lower priority 
level, and in this case the current task exits in a normal 
manner and the highest priority "waiting" task will become 



Loading through use of the queue stack requires use of the 
nonresident foreground area whether or not the request is to 
be loaded into this area. Therefore, whenever a nonresident 
foreground program Is loaded, all queue stack loading is 
suspended until the program occupying the nonresident fore- 
ground area releases the area by unloading. 



See the !ABS control command description in Chapter 2 
for restrictions regarding the use of the Absolute Loader. 
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TIME SEQUENCE 
Time Point 



T2 T3 T4 15 T6 17 T8 T9 TIO Til 
Note; Times need not be equally spaced. 



Activity (Meaning) 

TO The background is executing. 

Tl An interrupt is received for Foreground Task 2 which becomes active and saves the environment of the 

interrupted background task into its TCB. 

T2 Foreground Task 2 requests an I/O operation, specifies an AIO Receiver, and exits. The background 

resumes processing. 

T2.5 An interrupt is received for Foreground Task 3 which interrupts the BG. 

T3 An interrupt is received for Foreground Task 1 which becomes active and saves the environment of the 

interrupted task (Task 3) into its TCB. 

14 At channel end, an I/O interrupt is received for the operation initiated by Foreground Task 2; the 

I/O Interrupt Task saves the environment of the interrupted task (Task 1). The AIO Receiver is 
entered at the I/O interrupt level and triggers Task 2, indicated by dotted line at FGND 2 level. 
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Time Point Activify (Meaning) 



T5 



T6 



T7 



T8 



T9 



TIO 



m 



The AIO Receiver returns via a RCPY L,P instruction. The I/O Interrupt Task exits, restoring the 
interrupted task's status. Foreground Task 1 resumes operation, requests a checkpoint of the back- 
ground, and specifies a Checkpoint Complete Receiver. This action causes the RBM Control Task 
to be triggered, indicated by broken line at RBM Control Task level. 

Foreground Task 1 exits, restoring the interrupted task's status. This was actually Task 3, but Task 2 
is waiting and it immediately becomes active. 



Foreground Task 2 exits, restoring the interrupted task's status, 
and continues from where it was suspended. 



This was Task 3. It becomes active 



Foreground Task 3 exits, restoring the interrupted task's status. This was actually the background 
task. Since the RBM Control Task was triggered at T5, it is the highest waiting interrupt level. The 
RBM Control Task becomes active and stores the interrupted task's status into its TCB. The RBM 
Control Task calls the RBM Subtask SrCKPT which writes the background Into the RBM Checkpoint 
area on the RAD. SrCKPT then extends memory protection to the background and enters the specified 
Checkpoint Complete Receiver at the RBM Control Task Level. In this illustration the Checkpoint 
Complete Receiver triggers Foreground Task 1 with a Write Direct Instruction. 

Foreground Task 1 becomes active and saves the environment of the interrupted task In its TCB. The 
background area is now available to Foreground Task 1 for Instructions and/or data. When processing 
is complete. Foreground Task 1 requests a restart. 

Foreground Task 1 exits, restoring the interrupted task's status (In the Checkpoint Receiver, which 
returns via a RCPY L, P instruction). The RBM subtask S:CKPT now completes its operation and 
returns to the RBM Control Task which calls in the subtask S:REST to restart the background task. 
S;REST first clears the background area, then reads the checkpointed background task In from the 
RAD. The background is then set "unprotected" which completes the restart operation. 

The RBM Control Task exits, restoring the status of the interrupted background task which then 
resumes processing. 
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Two other methods of loading foreground programs are avail- 
able. They involve control commands normally used by the 
background, are part of a background job stack, and must 
be preceded by an FG key-in. These commands are 

!XEQ initiates loading from whatever RAD file to 

which background operational label OV is assigned. 
The method presumes that either the appropri- 
ate OV opib assignment has been made, or 
that the program to be loaded is on the RAD 
file RBMOV to which the label OV is assigned 
by default. 

Iname causes the foreground program "name" to be 

loaded in the same way a background processor 
is loaded. The foreground program must reside on 
either the System Processor or User Processor areas 
of the RAD. The user Is responsible for avoiding 
the duplication of program names. 

The control command methods are closely tied to back- 
ground schedules and do not provide adequate response to 
real-time needs. However, they can be used when de- 
bugging foreground programs. 



LOADING RESIDENT FOREGROUND PROGRAMS 

Loading of real-time programs into their predefined RAD 
files can be accomplished by the Absolute Loader from the 
background job stack, or resident foreground programs can 
be written into their predefined RAD files by the Overlay 
Loader. It is not necessary to create the foreground pro- 
grams when the system is created. However, to get the 
foreground program in absolute form will require either the 
use of the Overlay Loader or that the job be assembled in 
absolute as a self-contained package. 



LOADING NONRESIDENT FOREGROUND PROGRAMS 

Nonresident foreground programs are loaded by the Monitor 
service routine M:LOAD. Once loaded, these programs 
can be connected to an interrupt via an Initialization rou- 
tine or else can be triggered by a code given In the pro- 
gram's TCB. These programs then behave exactly like 
resident foreground programs. If the program just loaded 
resides in the area of core referred to as the nonresident 
foreground area, the nonresident foreground area is tied up 
until the program releases this space. Ordinarily, a program 
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releases space by a call to M:LOAD to "unload". How- 
ever, a FORTRAN program has no means of performing this 
unload except by calling a special library routine. A 
method is provided to automatically unload this area when 
MrABORT or M:TERM is called by the task occupying 
the nonresident foreground area. Therefore, a FORTRAN 
program calls the library routine L:OP (generated by the 
compiler when the program calls STOP) to terminate and 
unload. 



FOREGROUND INITIALIZATION 

When a foreground program is loaded, it may either be 
initialized*^ by RBM or may have its own initialization rou- 
tine (coded in assembly language). If the header of the 
foreground program contains a transfer address, RBM honors 
this address as the entry point to an initialization routine. 
This routine may arm and enable (or whatever) one or a 
number of related real-time interrupts. It can also set RAD 
files for subsequent use and set up initial values in core 
data tables. The initialization routine runs at the priority 
level of the RBM Control Task with the privileges of afore- 
ground program. The initialization routine should make no 
calls on routines requiring temporary storage, since the 
RBM temp stack is the one in use. When foreground 



See Overlay Loader options in Chapter 7. 



initialization is completed, theroutine returns to RBM via a 
register copy of Lto P. Foreground initialization routines will 
also be executed any time the system is rebooted from the RAD. 



TASK CONTROL BLOCK FUNCTIONS 

The Task Control Block (TCB) is a convenient means for 
organizing and storing information necessary to attain pro- 
per context switching, define dynamic blocking buffer 
pools, define temporary space necessary for reentrancy, 
and arm and enable the associated task. A foreground 
program may have one or more TCBs within the program 
(one for each task), but it is assumed that the first 
loadable item within a foreground program is a TCB. The 
TCB is used by the Monitor service routines M:SAVE, 
M:EXIT, M:LOAD, and by the Control Command Inter- 
preter upon encountering a !C: command. 



The TCB consists of 17 words and can be created at assembly 
time with Extended Symbol, or at load time by the Overlay 
Loader. (A FORTRAN program must have its TCB created 
by the Overlay Loader). The TCB is usually a block of 
code contiguous to the task it describes, with address literals 
pointing to the temporary stack space. A DATA statement 
can set the initial code for the interrupt level state for the 
task interrupt level. The complete contents of the TCB 
are shown in Table 17. 



Table 17. Task Control Block (TCB) 



Location 


Contents 


Set by 


TCB+0 


ADRL PSD 


Asse mb 1 e r/Loode r 


1 


0-3 


4 


5 


6 


7 15 


Assembler/Loader 


R-bit No. 
For WD 


T 





X 


Dedicated Interrupt Location 


2 


3 


4 


5 7 


8 11 


12 15 


Assembler/Loader 


0001 





Code 


0000 


Int. Group No. 


3 


ADRL TEMPBASE (temporary stack) (FWA) 


Assembler/ Loader 


4 


ADRLTEMPLIM (temporary stack) (LWA+1) 


Assembler/Loader 


5 


Contents of L register from interrupted task 


Current task (on actual entry) 


6 


Contents of T register from interrupted task 


M:SAVE (or current task) 


7 


Contents of X register from interrupted task 


M:SAVE (or current task) 


8 


Contents of B register from interrupted task 


MrSAVE (or current task) 


9 


Contents of E register from interrupted task 


MrSAVE (or current task) 


10 


Contents of A register from interrupted task 


Current task (on actual entry) 


11 


Contents of location 0006 (K:BASE) from interrupted task 


M:SAVE 
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Table 17. Task Control Block (TCB) (cont.) 



Location 


Contents 


Set by 


12 


Contents of location 0007 (K:TCB) from interrupted 
task. 


M:SAVE 


13 


Dynamic base (K:DYN) for temp of current task; 
initially TEMPBASE +6 


Assembler/Loader (changed by M:RES and M:POP) 


14 


Buffer pool LWA+1. 


Assembler/Loader 


15 


Number of buffers (1 < n <16)(0 if unused). 


AssembI er/Loader 


16 


"Use" bits for buffers in pool (0 if unused). 


M:OPEN or M:CLOSE 


PSD+0 


Interrupt task status flags 


Interruptsequence 


1 


Interrupted task P register 


Interrupt sequence 


2 


First instruction of current task 

Remainder of program (The PSD must be contiguous 
with the program but need not be continguous with 
the TCB.) 


Assemb 1 er/Loader 


where 




ADRL PSD is the Program Status Doubleword. It is the location shown in the dedicated interrupt location when 
the interrupt takes place. 


R-bit No. for WD is the hexadecimal value (from to F) that indicates the register bit that identifies the 
particular interrupt level within the Interrupt Group (the hardware block of 16 possible interrupts). 


T 


is the flag that indicates whether the M:SAVE and M:EXIT routines should set location 0001 to 0007; 
means yes, 1 means no, (T must be if any Monitor service routines are used, ) 


X 


indicates whether or not the task is to be triggered at load time: 1 means yes, means no. A code of 7 
is issued subsequent to issuing the code (normally 2, "Arm and Enable") given in word 2, 


CO 


DE is the interrupt system control code (as defined in the Sigma 2 and Sigma 3 Computer Reference Man- 
uals), that indicates current or desired initial interrupt control status. 


Buff 


er pool is an amount of space from one to 16 buffer areas in length, each of which is equal in size to the 
value contained in KrBLOCK. 


"Us 


e" bits are bits, from left to right, beginning with zero, showing which of the maximum number of buffers 
have been allocated by M:OPEN and have not yet been closed by M:CLOSE. 
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Note; The code In TCB + 2 is fhe exact code used in the 

Write Direct that sets the interrupt level. This code 
Is described In the Sigma 2 and Sigma 3 Computer 
Reference Manuals under "Interrupt System Control. ' 

Bit T in word TCB + 1 indicates whether the task is using 
the Monitor I/O routines and the floating accumulator; if 
bit T is zero, a temporary stack is required and theM:SAVE 
routine will initialize locations 0001 through 0006, after 
saving the previous pointers for the interrupted task. If 
bit T is a 1 (meaning no floating accumulator and no 
temporary space are required), the MiSAVE routine will 
not set these locations. In a real-time environment it is 
recommended that a user does not set the T bit to 1 (the 
floating accumulator and temporary storage pointers are 
saved). The Monitor service routines M:SAVE and MrEXIT 
do not, themselves, use any temporary storage. 

When the task is programmed in FORTRAN, the task en- 
trance and exit, TCB, and task entrance procedure are set 
up by the Overlay Loader. The module load routine 
M:LOAD sets the pointer to the PSD into the dedicated 
interrupt location and arms, enables, and optionally triggers 
the associated interrupt level. 

The background program will have a Task Control Block in 
protected foreground space. 

Caution: Locations 1 through 5 in the zero table are not 
saved and are recreated from location 6. Thus, 
locations 1 through 5 must not be changed by a 
foreground program or they will not be the same 
after an interrupt has taken place. 

When the Overlay Loader creates the TCB for a foreground 
task, the items shown in Figure 6 are generated adjacent 
to the task. The transfer address given in the object deck 
is not treated as the entry point to an initialization routine, 
but is used as the entry address for that task. The task will 
be armed, enabled, and possibly triggered when loaded for 
execution depending on the contents of words 1 and 2 of 
the TCB, supplied to the Overlay Loader on the !$TCB card. 

After a foreground program is loaded into core, certain 
items in the TCB are examined. A fatal load error results 
if the number of specified operational labels requiring 
blocking buffers exceeds the number of available blocking 
buffers (word 15 of TCB). If the number of available block- 
ing buffers is sufficient, word 15 of the TCB is adjusted to 
reflect the current blocking buffer requirements. 

In the event of a fatal load error in response to a load re- 
quest from a background job stock via an !XEQ or ! name 
command, the following message is printed on the DO: 



! lABORT CODE XE, LOCATION FFFF 

If the request came from a queue stack load, the following 
message is logged on the DO: 

NONRES FOND PGM xxxxxxxx LOAD ERROR 



If a program has an initialization routine, that routine is 
responsible for storing word of the TCB (the address to 
receive the interrupted task's PSD) into the dedicated in- 
terrupt location, as well as arming and enabling the appro- 
priate interrupt level for each task within the program. 

The initialization routine may also be used to assign any 
specific operational labels required by the program (e.g., 
the operational label or device unit number required to 
read in subsequent segments. 

If the program has no initialization routine, word of the 
first loaded task (actually word of that task's TCB) will 
be stored into the dedicated interrupt location for that task 
when the program is loaded. Next, the associated inter- 
rupt level is disarmed to remove any waiting interrupts; 
then it is armed, enabled, and possibly triggered, depending 
on the contents of words 1 and 2 of the TCB. 

When a foreground task is activated, control is transferred 
to the address given in the dedicated interrupt location, 
where the interrupted task's PSD is stored, and execution 
resumes at PSD+2 at the level of that foreground program. 
This is a hardware function that preserves the interrupt 
status and execution location of the internjpted task. Next 
the register contents of the interrupted task must be saved. 

Normally, the first instruction in a foreground program will 
store the contents of the accumulator into word 10 and the 
contents of the L register into word 5 of its TCB and then go 
to the Monitor service routine MrSAVE which will store the 
remaining register's contents into the active task's TCB. 
M:SAVE will also store the contents of K:TCB (used exten- 
sively by the Monitor to identify the currently active task) 
into word 12 of the TCB, and set K:TCB to point to the 
active task's TCB. If the active task requires temporary 
storage (word 1, T = 0), the contents of K:BASE are stored 
into word 11 of the TCB and K:BASE is set to the first word 
address of the active task's temp stack. The floating ac- 
accumulator is then set to point to the first six cells of 
the active task's temporary storage. 

When the currently active task has completed all its opera- 
tions, it exits through the Monitor service routine M:EXIT 
which restores the general register's contents and resets 
K:TCB and, if applicable, K:BASE. M: EXIT also performs 
a hardware exit sequence, by which it restores the interrupt 
status and the overflow and carry indicators, and returns 
to the interrupt task. 



FOREGROUND PRIORITY LEVELS AND I/O PRIORITY 

All foreground tasks with a priority level lower than the 
I/O priority level and operated without interrupts inhibited 
may use the Monitor I/O routines without any special re- 
strictions. However, foreground tasks that have Interrupts 
or have an interrupt level higher than the I/O priority level 
level must not use Monitor I/O. 

The recommended procedure for a task whose interrupt level 
is higher than the I/O priority level is to trigger a task 
whose priority is lower than the I/O priority. This lower 
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TEMP BASE 



TCB 



n-word 



^Word 

1 

2 

3 

4 
5 

12 

13 
14 

15 

Word 16 
Word n 



ENTRY 



Reserved Area 



ADRL Word n 



Interrupt Information 



TEMPBASE 



TEMPLIM 



K:DYN (Dynamic Temp Pointer) 



Buffer Pool LWA+1 



No. Available Buffers 



Use Bits 



PSD Reserve 



Foreground Task 



- exioc, specified on 
!$ROOTcard. 

n = temp, specified on 
!$R0OTcard; first five 
words of temp are float- 
ing accumulator; sixth 
word is used by FIO. 



STA 


TCB+10 


RCPY 


L,A 


STA 


TCB + 5 


RCPYI 


M 


B 


M:SAVE 


ADRL 


TCB 


B 


* $+ 1 


ADRL 


ENTRY 



TEMP LIM 

Supplied on !$TCB card. 

Temp Stack FWA. 
Temp Stack LWA+1. 

Reserve for saving con- 
text of interrupt task. 

Initially set to 
TEMPBASE + 6. 

Set to Common Base. 

Common Base — Last 
Loaded item/K:SEC. 

Initially set to zero. 

End of TCB 



Two-word reserve that 
■■ receives the interrupted 
task's PSD. 



Code to save registers, 
* TCB pointers, and temp 
pointers. 



Transfer Address 



Figure 6. Task Entrance Format 
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priority task would then perform the required I/O opera- 
tions. Generally, these high-level tasks are for emergency 
situations where no I/O is performed or when the task does 
Its own I/O due to special requirements. 



AlO RECEIVERS 

An AIO Receiver Is a means whereby a foreground program 
can initiate an I/O operation, release control to lower 
level tasks, and regain control when the I/O operation is 
completed. The AIO Receiver itself is o closed subroutine 
which operates at channel end (or zero byte count, if 
specified) at the priority level of the I/O interrupt. It is 
used in conjunction with an I/O operation specifying 
"initiate only and return" (no wait). Typically, in order 
to maximize compute and I/O overlay, the foreground pro- 
gram will issue an I/O request with the "no wait" option 
and specify an AIO Receiver. When the I/O operation is 
successfully initiated, this foreground task exits from the 
active state (by a call to M:EXIT) and is restored to the 
active status at channel end by a Write Direct to trigger 
the interrupt level (from its AIO Receiver). The next I/O 
operation for that device file-number must be a "check" 
operation to complete the end-action of the file. 

For I/O to RAD files, the AIO receiver may be activated 
before the operation is actually complete. This will happen 
whenever a transfer across a track boundary occurs, more 
than X' IFFF' bytes are requested, or a bad track is en- 
countered. The calling task (not the AIO receiver) must 
issue a "check" operation to complete the transfer. An AIO 
receiver specified for the "check" operation, will be 
honored. 

Special considerations for use of AIO Receivers are: 

1. The operation requesting an AIO Receiver is an 
"initiate and return" operation. If the device or the 
file is busy. The I/O operation is not initiated and a 
busy status Is returned. It is the user's responsibility 
to determine the course of action to be taken at this 
point (e.g., loop until ready or Ignore the operation). 

2. If the file being used is a blocked file, an actual I/O 
operation may not be required, hence no channel end 
Interrupt and no AIO Receiver operation. In this 
instance, the X register will be set to -1 to inform 
the user that the AIO Receiver will not be effective. 
A "check" operation is still required on the file be- 
fore another I/O operation may be performed. 

3. If the AIO Receiver merely retriggers the task that 
Initiated the operation, a danger exists in that it Is 
quite possible for the AIO Receiver to operate before 
the task exits from its "active" state. Thus, the cur- 
rently active task is retrlggered, which results essen- 
tially in a no-operation. One means of avoiding this 
problem would be to have the AIO Receiver set a flag 
to inform the active task that it has run. In this way, 
the active task could inhibit interrupts prior to exiting, 
test whether the AIO Receiver has already operated, 
and If so, restore interrupt status and return to the 



start of the task. If examination reveals that the AIO 
Receiver has not run, the task merely exits through 
M:EXIT which will properly restore the interrupt status. 
Another means of avoiding this difficulty is to have 
the AIO Receiver trigger a task lower In priority than 
the active task. This lower priority task could re- 
trigger the task Initiating the I/O operation, thereby 
providing a positive trigger. 

The form of the call to the AIO Receiver by the I/O Inter- 
rupt task is 



LDS 



AIODSB 



RCPYI P, L 



(device status byte 
from AIO In bits 0-7, 
device number in 
bits 8-12) 



B 



AIO Receiver Address 



The AIO Receiver routine must return to the location con- 
tained in the L register on entry. All registers are assumed 
to be volatile, which means that they need not be saved 
and restored to their former contents. Because the AIO 
Receiver is processed at the priority level of the I/O Inter- 
rupt, the processing in this routine should be of very short 
duration so as not to interfere with other I/O operations 
that may be In process. See also "End Action "in Chapter 5. 



CHECKPOINTING THE BACKGROUND 

A foreground program may require use of the background 
area for either Instructions or data. A checkpoint feature 
is included in RBM to allow access to the background area 
by a foreground program by writing any active background 
program onto the RAD and extending memory protection to 
the background area. 

A checkpoint operation is Initiated by a call to M:CKREST 
with the appropriate option. MrCKREST will return a status 
specifying whether or not the request was honored. The 
request will not be honored if the background has already 
been either checkpolnted by a foreground request or auto- 
matically checkpolnted as a result of loading a nonresident 
foreground program extending Into the background. It is 
the responsibility of the user to schedule the use of the 
background space by foreground programs. The actual 
checkpointing Is accomplished either at the priority 
level of the RBM Control Task or at the priority of the 
calling task. 

If the checkpoint is performed at the priority level of the 
calling task, a return from MrCKREST with a status of zero 
(A = 0) indicates that the checkpoint has been performed. 
If the checkpoint Is to be performed at the level of the 
calling task, the requesting program must exit its "active" 
state to allow the checkpoint operation to be performed. 
The program requesting the checkpoint would generally 
specify a "Checkpoint Complete Receiver". This receiver 
is operated at the priority level of the RBM Control Task 
when the checkpoint Is complete. 
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The receiver will generally retrigger fhe requesting pro- 
gram to inform it of the completion of the checkpoint. 
Return from the Checkpoint Complete Receiver is to the 
location contained in the L registers on entry. All registers 
are assumed to be volatile, and need not be saved and re- 
stored to their former contents. 

When the foreground program no longer requires use of the 
background area, it should restart the background task by 
a call to M:CKREST with the "restart" option. 



FOREGROUND CODING PROCEDURES 

Conformity to the following conventions in coding fore- 
ground programs will increase the chances of recovery from 
a power failure: 

1. Normally, when a task performs its own input/output, 
it will inhibit interrupts before it checks channel status. 



loads the channel registers, and issues the SIO. If the 
SIO instruction occurs within the 16 cells following 
the inhibit instruction, the Power On Task will be able 
to determine that I/O has not been initialized on this 
channel (if a power failure occurs after the interrupts 
are inhibited but before the SIO is issued) and there- 
fore will not simulate an I/O interrupt. 

2. If any task that uses the counter-equals-zero interrupt 
resets the dedicated Interrupt location to zero before 
unloading or exiting, the Power Off Task will not arm 
and enable this level. This will prevent spurious 
interrupts, 

3. For all Sigma 2 interrupts and the Sigma 3 external 
interrupts, the interrupt status is determined through 
the TCB chain (each TCB contains the address of the 
TCB of the task last interrupted). Therefore, any task 
that has entered its TCB in this chain will be re- 
activated. Entering the TCB chain is normally per- 
formed via a call to MrSAVE. 
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7. OVERLAY LOADER 



The Overlay Loader can be used to create overlay programs 
for later execution in either the foreground or background. 
Overlaid programs can be permanently entered (as a file) 
into either the system or user processor areas, or into a 
temporary overlay file. Since they ore stored on the RAD 
as an absolute core image, they can be quickly loaded into 
memory for execution. 

A general overlay structure is illustrated in Figure 7. The 
structure is restricted to a permanently resident root seg- 
ment and any number of overlay segments. (For background 
and nonresident foreground programs, the permanent root 
segment is resident only during actual execution.) For fore- 
ground programs, the TCB and the initialization routine 
(if one is present) must be in the root segment, but data 
and instructions can be located in both the root and the 
overlay segments. 

A COMMON data area can also be established for use by 
the root and overlay segments. 

Each segment is created by the Overlay Loader from one or 
more object modules (assembly language, FORTRAN, or 
library routines). The control commands required to create 
the overlay segments are defined in this chapter. During 
execution, the Monitor service routine MrSEGLD is used to 
control both the loading and the transfer of control between 
various segments- 

The overlay segments must be explicitly defined at load 
time and explicitly called at execution time. There is no 
provision for automatically calling in a new overlay seg- 
ment by a subroutine reference. However, the subroutines 
on a particular path may communicate with each other, with 
the restriction that it is the program's explicit responsi- 
bility to ensure that any subroutine referenced is cur- 
rently in core. 

The Overlay Loader accepts input in Standard Sigma 2/3 
Object Language from predefined, preposltioned files, and 
prepares output in absolute core-image form on the RAD to 
be read by the RBM Loader (MrLOAD) for later execution 
in either foreground or background areas. If a resident or 
nonresident program can tolerate a loading delay of 20 to 
100 ms, foreground or background programs of virtually un- 
limited size can be constructed by the use of overlays de- 
spite limitations in available core storage. 

In creating core images on the RAD, the Overlay Loader 
performs the following functions according to user options: 

• Satisfies external reference/definition linkages and 
resolves forward reference and displacement chains. 

• Searches specified libraries for unresolved references 
and loads these selected routines into core memory. 

• Builds the OVrLOAD table for the loading of overlay 
segments. 



Writes the overlay cluster onto the OV file. 

Allocates COMMON. 

Allocates temporary storage stacks. 

Creates a Task Control Block (TCB) and initialization 
information. 

Creates the Public Library and associated transfer 
vectors (TVECT). 

Outputs maps of segment names and addresses, external 
definitions, and information concerning COMMON 
and temporary areas. 



OVERLAY CLUSTER ORGANIZATION 

The overlay cluster is the collection of absolute overlays 
formed by the Overlay Loader from relocatable binary ob- 
ject modules. (Note that the Loader does not accept an 
absolute load origin in any input module.) An overlay 
cluster usually consists of two principal sections: the root 
segment and the overlay segments although it may consist 
of only a root segment. Each segment consists of one or 
more binary modules and associated library routines. Over- 
lay segments are numbered in any order by the user, except 
for the root segment, which is always designated as seg- 
ment 0. Those segments in core memory at any one time 
form a path. Another overlay cluster with several paths 
is shown in Figure 8. Segments are shown as horizontal 
lines and, in this example, are numbered in the order In 
which they are built by the Overlay Loader. Note that at 
a given node, each path associated with a branch must be 
completed before a new branch is connected to this node. 

The overlay cluster shown above consists of a root and seg- 
ments 1 through 15. Segments 0, 1, 3, 4, 5, 6 constitute 
a path. On the RAD or disk pack the root Is preceded by 
a file header, one RAD granule in length, that contains in- 
formation by which the RBM Loader M:LOAD can correctly 
read the root. The root is resident at all times during exe- 
cution of the overlay program and contains information 
(OV:LOAD table) for loading of the remaining overlay 
segments. 

Communication between segments by external reference/ 
definition linkages is subject to the following restrictions: 

1. No segment in a path may reference a segment in 
another path. 

2. The user must ensure that all communicating segments 
are in core memory during execution. 
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Root 

(Segment- 
No. 0) 



Overlay Segmeni- n 



Overlay Segment No. 3 



Overlay Segment No. 2 



Overlay Segment 
No. 21 



Overlay Segment 
No. 22 



Overlay Segment No. 1 



Blank 

COMMON 
Data 
Area 



Root Area 



Overlay Area 



COMMON 

Area 

(Optional) 



Low Core — 



High Core 



Figure 7. General Overlay Structure Example 
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Figure 8. Sample Overlay Cluster Configuration 



3. Because the Overlay Loader will satisfy a linkage only 
within a path, identical references and definitions 
may be used in different paths that do not contain a 
common segment. However, the user must avoid refer- 
ences to the same definition in different higher level 
segments. 

To satisfy any remaining unsatisfied primary references, 
the Overlay Loader searches the following libraries in the 
specified sequence: 

1 . Public Library 

2. Monitor Service Routines 

3. Basic or Extended Library 

4. Main Library 

CORE LAYOUT DURING LOADING 

Background memory during the operation of the Overlay 
Loader is divided into four sections: 

1. A fixed area large enough to contain the background 
temp stack, the Overlay Loader root, and the Loader 
overlays. 

2. The segment table, fixed at 10 (n + 1) where n equals 
the number of segments, which contains the user's 
OV:LOAD table. 

3. A dynamic area in which the segment is loaded. 

4. A dynamic area containing the symbol tables (alloca- 
tion is eight words per symbol). 

If areas 3 and 4 overlap at any point in the load process, 
overflow occurs and loading aborts. 



OVERLAY LOADER OPERATIONAL LABELS 

The Overlay Loader references the operational labels listed 
below. Some assignments are user-defined, while others 
are handled internally by the Job Control Processor or by 
the Overlay Loader itself. All other operational labels 
referred to on !$LD cards must be assigned and positioned 
by the user prior to the lOLOAD card. 

Label Explanation 

CC Control commands. 

DO Control commands as read from CC, maps, and 

diagnostic messages. The default assignment is 
that given by the Job Control Processor on read- 
ing a ! JOB card. 

GO Sequential-access file that contains object mod- 

ules to be processed by the Overlay Loader. 
Object modules are written onto GO by a pre- 
ceding processor. The Loader rewinds GO 
initially. GO receives a default assignment by 
the Job Control Processor to the permanent file 
RBMGO in the System Data area. 

LI Assigned internally to System or User Library as 

library searches are performed. 

OC Abort messages and Overlay Loader messages 

that require operator attention. 

OV Output file for the Overlay Loader containing 

the completed overlay cluster. If the user wishes 
to have the overlay cluster in a pemianent file, 
he must key in SY (for write -protected files) and 
assign OV to that permanent file. By default, 
OV is assigned to the permanent file RBMOV in 
the System Data area. 

PI Used for loading the Overlay Loader's own 

overlays. PI is assigned by the Job Control 
Processor. 

XI Temporary RAD or disk pack scratch file con- 

taining the symbol table for each segment. 
XI is assigned by the Job Control Processor. 

RS Assigned internally to read the RBM Symbol 

Table (RBMSYS) from the System Data area. 

LS Assigned internally to read the Public Library 

Symbol Table (LIBSYM) from the System Data 



ID An optional operational label used to write 

the idents of nortlibrary programs for use by 
Debug at execution time. If the user assigns 
ID, the assignment must be for a blocked file 
that has a record length of five words. By 
default, ID is assigned by the Job Control Pro- 
cessor to RBMID '^a one-sector file) in the System 
Data area. 
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MAP 



Three types of maps may be output to the DO device 
following PASS2, according to one of three MAP con- 
trol commands that may be input: a SHORT map (l$MS), 
LONG map (!$ML), or PROGRAM map (!$MP). If 
no map control command is specified, no map will be 
output. 



Figure 9 shows the format for a LONG mop. Note that 
DBFs in the Permanent Symbol Table are mapped after the 
Overlay Task line. The format for a PROGRAM map would 
be the same as the LONG map except that library and 
Permanent Symbol Table symbols are suppressed. The lines 
of the map that are flagged with an asterisk (*) show the 
format and output of a SHORT map (in an actual SHORT 
map no asterisk would appear in the listing). A definition 
of each item of the map is included in Figure 9. 



*MAP 



•OVERLAY TASK 



fFOl 

IbaJ 



ORG = xxxx HLLOC = xxxx CBASE = xxxx CSIZE = xxxx UMEM = xxxx SECT = xxxx 



fNONEl 
-ROOT ORG = xxxx LWA = xxxx LEN = xxxx TRA = i \ SEV = xxxx OVrLOAD = xxxx 

IxxxxJ 



[f 1 DEF S S S S S S^S^S L/I S/U/P B/E/M yyyy 
1-* 12345678 

[f f ]rEF S S S S S S S S LI S/U B/e/M zzzz 



-SEGMENT IDENT NODE ORG LWA LEN TRA SEV 

xxxx xxxx xxxx xxxx xxxx xxxx xxxx 



[f ] DEF etc 



[f f ]rEF etc 



REF 



''-SEGMENT 



^SEGMENT 



*ERRSEV = xxxx 
*END MAP 



where header keywords have the following meaning: 
Overlay Task Keywords 



ORG 
HLLOC 
CBASE 
CSIZE 



First word address of the Overlay Task area. It is the FWA of the Temp stack. 

Last word address of longest segment. 

Base of COMMON. 

Largest COMMON size encountered. 



Figure 9. Load Map Format 
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Overlay Task Keyworc 


s (cont.) 


UMEM 


The number of locations between the end of the longest path, and either the beginning 
of COMMON or the end of the assigned task area. 


SECT 


The number of sectors required to store entire overlay cluster. 


Root Keywords 




ORG 


FWA address of the root. In the foreground, this is assumed to be the address 
of the TCB; in the background, it is the FWA of the root. 


LWA 


Last word address of the root segment. The area from ORG to LWA includes 
the root code and the OV:LOAD table (and in the foreground, the TCB). 


LEN 


LWA-ORG+1. 


TRA 


Background — last end transfer encountered on a module used to form the root. If there 
is no transfer address, 'NONE' is output. 




Foreground — the entry address of an initialization routine that arms and optionally 
triggers interrupts at run time. If the Loader builds the TCB, it is assumed that no 
such initialization exists and TRA=NONE. 


SEV 


Error severity encountered during loading binary modules. Taken from the END item of 
the binary module. 


OVrLOAD 


Address of the OVrLOAD table. 


General Keywords 




^^2 


Error and identifier flags preceding external definitions and references. Possible flags 


1 £. 


are: 




D Double definition or reference. 




U (DEF) — a definition declared, but given no value. 




U (REF)— reference unsatisfied in this path. 




P Primary reference. 




S Secondary reference. 


DEF 


An external definition. 


REF 


An external primary or secondary reference. 


S^...S3 


EBCDIC DEF/I^EF name of one to eight characters. 


L/I 


Library or Input REF/DEF. 


S/J/P 


System, User, or Public Library. 


B/E/M 


Basic, Extended, or Main mode- 


yyyy 


Value of a DEF. 


zzzz 


The number of the segment in which this reference was satisfied. For unsatisfied 
references, zzzz is blank. 





Figure 9. Load Map Format (cont.) 
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Segment Keywords 




IDENT 


Numerical identifier of this segment as found as the first parameter on the !$SEG card. 


NODE 


The numerical identifier of the segment to which this one will be attached. If NODE 




is the root, is output. 


ORG 


Beginning location (execution) of this segment. The point in core at which loading 




begins. The first reserves before data In a segment are not output. 


LWA 


LWA of this segment. Includes areas defined by RES and ORG. 


LEN 


LWA-ORG+1. 


TRA 


The last encountered transfer address is placed as an entry point in the OVrLOAD table 




for this segment. 


SEV 


Same as for ROOT. 


ERRSEV 


Total error severity for loading process (0 or 1). If any SEV > or there are unsatisfied 




primary references, ERRSEV=1. Only in forming a PUBLIB do double DEFs cause 




ERRSEV=1. 


END MAP 


Completion of loading process. 



Figure 9. Load Map Format (cont.) 



CALLING OVERUY LOADER 

The Overlay Loader Is requested via an lOLOAD com- 
mand which causes the root segment of the Loader to 
be read into core memory from the RAD. The form of 
the command is 



lOLOAD [segments, | | ,S,D,X,cmn] 



segments denotes the number of segments in the 
overlay cluster. If "segments" Is not specified, 
a zero is used, denoting that only a root segment 
is to be loaded. The value of the segments param- 
eter may exceed the actual number of segments to 
be loaded. 

F or B specifies either a foreground (F) task or a 

background (B) task. The default case is 
background. 

S specifies a step mode of loading to be used for 

paper tape input. 

D indicates the ident of each nonlibrary module is 

to be written to operational label ID for use by 
Debug at execution time. 



X indicates that the Loader is to abort the job if 

a severity error greater than zero is encountered 
during loading. The loading procedure Is com- 
pleted and the map Is output. 

cmn for background tasks, cmn denotes an optional 

COMMON size; for foreground tasks, cmn denotes 
either a base for COMMON or. In the case of 
zero COMMON, the upper limit of the task area. 

When the step mode of loading is defined, the operator is 
notified after the loading of each module from paper tape 
by the message 

! IBEGIN WAIT 

Depressing the console interrupt button and keying In an S 
will Initiate either the loading of the next module from the 
paper tape unit or the reading of the next control command. 
An X response causes the loading process to abort. 

In allocating COMMON for background programs, the 
Overlay Loader compares the cmn parameter with the first 
nonzero COMMON size allocation value encountered in 
loading and employs the larger of these two values. The 
COMMON base is set by subtracting the COMMON size 
from KrUNAVBG. 

For foreground programs having COMMON, cmn denotes 
the base (i.e., FWA) of COMMON. In this case the 
effective upper limit of the program is cmn plus the largest 
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COMMON size allocation value encountered In loading. 
For foreground programs in which COMMON is allocated, 
but in which cmn has not been specified, the COMMON 
base is set by subtracting the first nonzero COMMON size 
allocation value encountered from K:BACKP-1. For fore- 
ground programs having no COMMON, cmn may be used 
to specify an upper limit for the program. If the program 
exceeds the limit, the Loader aborts. The default value 
of the area upper limit for foreground programs without 
COMMON is the upper limit of the nonresident foreground 
area (K:BACKP-1). 



The Loader makes no distinction between programs loaded 
in resident and in nonresident foreground. 



through 9; or (4) a string of the form EBCDIC 
string ± hexadecimal number. 



From one through eight blanks are permitted between the 
mnemonic and the first parameter. If more than eight 
blanks are detected, the parameter list is considered empty. 



The only allowed delimiter between parameter fields is a 
comma; no embedded blanks are allowed in or between any 
fields. A single blank terminates the parameter string. 
Two successive commas indicate an empty field. Comments 
are allowed on a control card. 



Reading an !EOD control command causes the Overlay 
Loader to satisfy forward references, output any specified 
map, close files, and return control to RBM via MrTERM. 
The form of the command is 

lEOD 



CONTROL COMMAND FORMAT 

Except for the lOLOAD command, which is read by the 
Job Control Processor, the Overlay Loader control com- 
mands are read from the CC device under Loader control. 
The general format of control commands is 

^ 

!$mnemonic parameter 



where 



identifies the record as a control command. 



indicates that the control command is unique to 
the Overlay Loader. 



mnemonic is the code name of an Overlay Loader 
control command and begins immediately follow- 
ing the ! $ characters. 



parameter is a series of optional or required param- 
eters unique to the specific command. The formats 
of parameters are (1) a decimal integer of up 
to five positive numbers but having a value less 
than 32,767; (2) a hexadecimal string of the 
form ±xxxx; (3) an EBCDIC string of up to eight 
characters but not exclusively characters 



CONTROL COMMAND REPERTOIRE 

BLOCK The l$BLOCK control command defines oper- 

ational labels that may require blocking buffers at run 
time. The list of such labels along with limits of avail- 
able memory will be passed via the file header to 
M:LOAD, which will allocate a blocking buffer pool at 
run time. The pool will be utilized dynamically to 
provide blocking buffers in cases where a call to RBM 
routines M;READ or MrWRITE is not preceded by a call 
to M:OPEN. A call to M:CLOSE may release any such 
buffers. Thus, if two operational labels were to use a 
blocking buffer area at different times, the first might 
release the area for use by the second. Only one of 
the two labels would be required on the l$BLOCK 
command. 



MrLOAD checks which of the operational labels are as- 
signed to block files at run time to make the pool allo- 
cation. If such an allocation overflows the available 
memory space (between the end of the longest path and 
COMMON), the execution aborts. However, the user 
may define his own blocking buffer by specific calls to 
MrOPEN. Such an area should be in a reserved area 
of his own path. He should not use the dynamically 
allocated pool area, and blocking buffers may not be 
allocated in temporary stacks. Only one !$BLOCK 
command is allowed in a single job step. The format 
of the l$BLOCK command is 



!$BLOCK oplb^,oplb ,...,oplb^ 



where opibj defines an operational label (which is a two- 
letter mnemonic or a FORTRAN device unit number; e.g. , 
BI, SI, F:I06). The opib] parameter may not be a device- 
file number or file name. The opib must be assigned to 
a block file. 



LIB The !$LIB control command specifies a new default 
library loading mode for the entire loading process. If the 
LIB command is not present, the Overlay Loader follows 



78 Control Command Format/Control Command Repertoire 



the default case (Basic System Library). ! $LIB cards may 
occur at any point in the control deck and will take effect 
from that point. The format of the command is 

!$LIB library,xr,y] 



where 

library must be one of the following EBCDIC codes. 
Code Library 



Basic 
Extended 



x,y specify the order of search. The x and y pa- 

rameters areeitherof the following EBCDIC codes. 

Code Library 



System 



User 



The order in which they are specified determines the 
order of search. Note that if y is not specified, only 
X will be searched. 



The output of the ! $MP control command is identical to 
that of !$ML, except that library definitions and references 
and the permanent symbol table are suppressed. The format 
of the command is 



$MP 



If relevant, information concerning the Public Library is 
also mapped. 



TCB The !$TCB control command indicates (for a fore- 

ground task only) that the Overlay Loader must create a 
TCB and reserve a PSD location, and must generate a call 
to RBM routine MrSAVE. In addition, information to ini- 
tialize the TCB at run time will be passed in the file header. 
If no !$TCB command is present, it is assumed that a TCB 
has been assembled into the root segment. Since the back- 
ground TCB lies in protected memory, it cannot be assem- 
bled into the root of the background overlay cluster, but the 
necessary information is passed by the Loader to MrLOAD 
via the file header. Therefore, the TCB option applies to 
foreground tasks only. The I $TCB command must precede 
the !$ROOT command. The format of the command is 



$TCB w^,W2 



MS ML MP The MAP control commands specify that 

map information is to be output on DO. The three forms of 
map commands are shown below. 

If the I $MS (Short Map) control command Is specified, only 
root and segment headers will be output. Also output is a 
summary containing the origin of the overlay program, the 
length of the longest path, temp stack size, memory that is 
available for the blocking buffer pool, and the COMMON 
base. The format of the command is 

!$MS 



If the !$ML (Long Map) control command is specified, the 
short map plus external references and all external defini- 
tions and their values including the libraries and permanent 
symbol table are output. Double definitions, and definition 
declarations that were not given a value are flagged D 
and U, respecitvely. Unsatisfied primary references 
are flagged with UP, unsatisfied secondary references with 
US. The format of the command is 



!$ML 



where w- are the values to be placed in words 1 and 2 of 
the created TCB. (See Chapter 6, Real-Time Programming. ) 

The Overlay Loader will handle specific and default 
cases of program execution and TCB initialization within 
the framework of the following restrictions: 

• The Overlay Loader defines all background Task Con- 
trol Blocks completely, using the value of the temp 
parameter on the ! $ROOT card, load information, and 
the !$BLOCK parameters. 

• In foreground tasks, If the user assembles the TCB as 
part of the program, it either must contain all informa- 
tion as data or as external references satisfiable at 
load time, or be initialized by the task itself. A trans- 
fer address is assumed to be a transfer to an initializa- 
tion section that will do any required housekeeping, 
arming, enabling, or triggering the task. If no trans- 
fer address exists, MrLOAD will arm and enable and, 
optionally, trigger the task using information In 
words 1 and 2 of the TCB. 

• If the Overlay Loader initializes the TCB by means of 
the TCB parameters, it does so completely, using load 
information and values on the ! $TCB and !$BLOCK 
cords. No partial Initialization of a TCB is allowed 
with the exception of the blocking buffer pool. If a 
user builds his own TCB, the TCB must begin at the 
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execution location plus the "temp" value specified on 
the l$ROOT command. 

For foreground tasks for which the Loader builds a TCB, 
the Loader will create the PSD reserve and a call to 
MrSAVE. The user's root is then entered either at the 
location specified in the transfer address, or at the 
FWA of the root when the transfer address is missing. 
The map will indicate a transfer address of "NONE" 
for the root. 



oplb,n specifies that n modules are to be loaded 

contiguously from the operational label opib. No 
default is provided. 

Note that if the opIb parameter is absent, l$LD (Load) or 
!$INCLUDE control commands must follow l$ROOT to 
specify loading. If opIb is present and the n param- 
eter is empty, loading proceeds from opIb until an I EOD 
is encountered. 



The user exits with either a call to the RBM routine M:EXIT 
or by a standard exit procedure. 

Public Library routines and Monitor service routines called 
by the user program will require temporary storage areas 
that are dynamically allocated at execution time. These 
temporary storage areas must be allocated in a fixed storage 
stack that is reserved by the Loader at load time on the 
basis of the temp parameter on the 1 $ROOT control com- 
mand. In addition, the Loader will insert in the TCB the 
first and last word addresses of the area. The temp area 
will be allocated preceding the root segment. It need not 
be a reserve in the module. 

For more information on initialization and structure of TCBs, 
see Chapter 6. 



ROOT The !$ROOT command specifies that the modules 

that follow it constitute the root segment of the overlay 
cluster. A I $ROOT command must precede all !$SEG com- 
mands, and may be followed by !$LD, !$INCLUDE, !$A/ID, 
!$LIB, and l$LB commands, which cause the loading of 
those modules that form the root segment. Loading of the 
root will begin at the first cell following the temp stack for 
the background task. An execution bias may be specified. 
The user must ensure that the root segment, exclusive of any 
library loading, is less than 32K bytes. The root and its 
library are written as two records. Therefore, the library 
portion of the root may also be a maximum of 32K-1 bytes, 
which gives a maximum root size of approximately 32K 
words. The format of the command is 



$ROOT [temp,exloc,oplb,n] 



wh( 



temp defines the size of the overlay cluster's tempo- 
rary stack needed for the largest possible nesting 
of Public Library and Monitor service routines. 
The default size is 80 cells. 

exioc specifies the beginning location of the area 

in memory that the overlay cluster will occupy at 
execution time. The default case is K:BACKBG 
for a background task and KtNFFWA for a fore- 
ground task. The temp stack will be allocated at 
exIoc 



LD The !$LD control command identifies one or more 

modules to be loaded as part of a segment. Each input file 
must be ordered in the same sequence as the 1$LD cards in 
the control stack accessing that file. The Overlay Loader 
reads only relocatable binary modules from the GO file and 
other input files specified on !$LD, !$SEG, and !$ROOT 
cards. All files must be pre-positioned (GO is rewound by 
the Loader), and the modules must be in the same position 
on each file as calls on that file. The use of the IDNT on 
the !$LD card ensures the loading of the proper module. 
Note that the file must be positioned to the proper module 
in the file when the Loader reads from that file. Since 
there are no file-positioning control commands recognized 
by the Overlay Loader, each file must be constructed in 
correct sequential order. The form of the command is 



!$LD 



[opib] , [i^* 



dent! 
m J 



opIb is the operational label of the medium from 

which the binary module is to be loaded. The 
default case for an empty field is GO. 



fidentl 
Inm J 



ident is an EBCDIC representation of the 
IDNT of the program to be loaded. It is 
used for checking purposes only. If nm is speci- 
fied, it indicates the number of modules to be 
loaded from opIb; no check of any ident is made. 
If this parameter is empty or is an ident, one mod- 
ule is loaded. 



LB The $!LB command controls the search of libraries 
(for this segment only) to satisfy external references en- 
countered during the loading of modules forming the seg- 
ment. If the !$LB control command is omitted, the 
Overlay Loader will first attempt to satisfy all references 
by definitions in other segments of that path or from the 
root, and then will search the libraries specified by I $LIB 
or by the default case. Individual !$LB cards supersede 
!$LIB or default for that segment only. Libraries are 
searched only on occurrence of a !$SEG or I EOD control 
command. !$LIB and !$LB cards only set the mode and se- 
quence of search. Only libraries on the RAD or disk pack 
maybe loaded selectively using the !$LB command. To 
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input "library" programs from other media, the user must 
use standard ! $LD commands. The format of the com- 
mand Is 

A 



$LB library, m[,n] 



whf 



library must be one of the following EBCDIC codes: 
Code Library 



B 



Basic 



Extended 



and that any labels used are defined for the path the seg- 
ment lies in. The Overlay Loader aborts if the modifica- 
tion location lies outside the limits of the segment. 
Inserted values are not tested for range. External symbols 
(definitions) used in loc or value must have been previ- 
ously defined. The format of the command is 

! $MD loc, value r,value,,value_, ... ,value J 
I z n 



wh< 



loc specifies the execution location of the first 

modification. 



ilue| is the hexadecimal quantity to be inserted 

at loc + i (for example, value is Inserted at loc, 
value, at loc + 1, etc.). 



m r, n] specify the order of search. The m and n 

parameters are either of the following codes: 



Code Lib 



rary 



Both the loc and the value; parameters are subject to the 
restrictions set forth in "Control Command Format". Note 
that It is not possible to modify a library module by use of 
Qx\ !$MD control command. 



System 



User 



If n is not specified, only m will be searched. There are 
no default cases for E, B, m, and n. 



INCLUDE The I $INCLUDE control command specifies 

external definitions in those library modules that are to be 
loaded with this segment, even though they are not refer- 
enced in the segment. Their definitions will be included 
In the Symbol Table for use by higher-level segments. 
More than one !$INCLUDE command may be used. Li- 
braries are searched according to a preceding !$LB or ! $LIB 
card or the initial default case. The format of the com- 
mand is 



!$INCLUDEdef^,def ,. 



,def 



where def; is an external definition of a library program to 
be Included in the segment. 



MD The ! $MD (modify) control command is used to 

change core locations at load time before the absolute 
overlays are written out onto the OV file. ! $MD commands 
must be inserted within a SEG sequence and apply only to 
the segment being loaded. A check is made that the 
effective address of the ! $MD command lies in the segment 



SEG The l$SEG control command defines the modules 

that will form a segment. Numbers used to define a segment 
must be unique. Segment identifier numbers need not be 
consecutive. A segment, including its library, is restricted 
to a maximum of 16,112 bytes since the segment and Its 
library are written as one record on the RAD. 

Each !$SEG or $!ROOT control command may be followed 
by !$LD, !$MD, !$INCLUDE, l$LIB, and ! $LB commands 
to load the modules to form that segment. The loading for 
a segment terminates on a new !$SEG control command. 
The control command stack is terminated by an !EOD. The 
user may not defer library loading to a higher level seg- 
ment. The Loader will attempt to satisfy all references 
present at a level from the libraries specified on !$LB, 
l$LIB, and !$INCLUDE commands or from the default li- 
brary case. A given library Is searched only once per 
segment. The format of the command Is 

!$SEG si,sn[, oplb,n] 



wh< 



si is a number less than or equal to X'FF' used to 

identify the segment being loaded. It will be 
used to call the segment at run time. 

sn is the number of the segment to which this seg- 

ment Is attached. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label opib. 
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The following rules should be observed In defining segments 
for the overlay cluster: 

1. The longest segment must fit into core with the Loader 
and its tables. If a segment is too long. It may be re- 
assembled as two modules and loaded as two segments. 

2. The Loader will first attempt to satisfy library refer- 
ences using the Public Library and then will search the 
appropriate libraries on the RAD or disk pack. Using 
the l$INCLUDE command, other often-used library 
routines can be loaded with the root where they will 
be accessible to all segments. However, library rou- 
tines loaded in any segment will be accessible only to 
segments In the same path. 



At execution time an explicit call to RBM routine MrSEGLD 
with the segment identifier number and the ADRL OVrLOAD 
causes the reading of that segment Into memory from the 
OV file. Thus, any segment may, by an explicit call, 
cause any other segment to be loaded for execution. 



PUBLIB The l$PUBLIB control command Indicates that 

the Overlay Loader is to create a Public Library using mod- 
ules that follow and/or modules from selected libralres. 
The Public Library Is biased at the location specified In 
KrPLFWA of the RBM. Each symbol is flagged as Extended, 
Basic, or Main according to control information on the 
!$PUBLIB card. However, a library may contain routines 
of more than one mode. Such identical definitions of 
different modes are differentiated in the Symbol Table 
(LIBSYM) and are not considered duplicate. 



When library routines are port of the Public Library, they 
must be reentrant and therefore must use the dynamic tem- 
porary stack (specified as the temp field on the I $ROOT 
command) for their temporary storage space. To conserve 
core space when forming the Public Library, the Loader 
will remove any trailing RES from a library routine and will 
also change the appropriate word in the calling sequence 
for M:RES, MrPUSH, or MrPUSHK so that the dynamic 
temporary stack will be used for temporary storage space. 



A severity level of 1 is set if unsatisfied references or 
double definitions are encountered during the loading of a 
Public Library, and the library will not be written onto the 
PUBLIB file. When a Public Library is being created, the 
Overlay Loader creates a new Public Library on the RAD 
or disk pack. The Public Library fust loaded is written 
onto the PUBLIB file in the User Processor area. The total 
length of the Public Library must not exceed 8191 words. 
The Monitor Services Transfer Vector (TVECT) file is read 
from System Processor area, and the Public Library section 
Is updated and written onto TVECT. A new Public Library 
Symbol Table Is written to LIBSYM file in the System Data 
area. The new LIBSYM Is Incompatible with the Public 
Library currently In core. All files are closed and nor- 
mal termination through MrTERM takes place. The new 



Public Library is then loaded into core by rebooting the 
RBM. The format of the command Is 

!$PUBLIB library mode [,oplb,n] 



whe 



mode must be one of the following EBCDIC 
codes: 



Code 



Mode 



B 


Basic 


E 


Extended 


M 


Main 



A new !$PUBLIB <iontrol command must be pro- 
vided each time mode Is to be changed. 

oplb,n specifies that n modules are to be loaded 

contiguously from the operational label opib. 

I$LD, l$LB, !$INCLUDE, and I $MD commands are hon- 
ored when using l$PUBLIB In the same manner as for the 
!$SEG command. !$ROOT, ! $TCB, and !$SEG commands 
may not be used in conjunction with the !$PUBLIB command. 



END The !$END command is treated exactly like an 

!EOD command. It should be used in place of !EOD when- 
ever multistep job stacks are to be prestored on a RAD file. 
The Utility COPY routine will not interpret this com- 
mand as end-of-file (EOF). The format of the command is 

!$END 



LOADER ERROR MESSAGES 

The Overlay Loader program outputs messages on both OC 
and DO concurrently with the load operation. If OC and 
DO are assigned to the same device, duplication of mes- 
sages on DO is suppressed. If an operator response is re- 
quired, the message 



! IBEGIN WAIT 



is written on OC and DO. The operator activates the con- 
sole interrupt and keys in either of the following codes. 



Code 

S 

X 



Meaning 



Continue. 



Abort Overlay Loader and return control 
to RBM. 
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The format of the error message where an operator response 
is required is 



OLERR XX 



where xx is a two-letter mnemonic that identifies the error. 

The types of Overlay Loader messages are as follows: 

1. Warning messages, after which loading 
continues. 



2. Response messages, requiring on S or X key-in from 
the operator. 



3. Abort messages, upon which the Overlay Loader exits 
via the RBM routine MrABORT (see Appendix C for 
abort codes, abort messages, and their meanings). 



The Overlay Loader error messages are given in Table 18 
below. 





Table 18. Loader Error Messages 


Message 


Meaning 


LIBSYM UNDEFINED^ 


There was no file entry on the System Data area of the RAD or disk pack for 
the LIBSYM table. 


OLERR CC !! BEGIN WAIT 


A control command card has a format or parameter error. An S response 
causes the next control command to be read in from CC. This may be a 
corrected command to replace the one in error. *■*■ 


OLERR CS !!BEGIN WAIT 


There was a checksum error on a binary record. An S response causes the 
record to be reread. 


OLERR IB !! BEGIN WAIT 


Illegal binary format (that is, the first word was not 'FF' or '9F') was 
detected. An S response causes the record to be reread.''^ 


OLERR ID !! BEGIN WAIT 


The indent on the binary module just loaded does not compare with the ident 
specified on the !$LD command. On an S response, the Loader accepts the 
binary module as is and continues processing. 


OLERR IS MBEGIN WAIT 


Control commands were improperly sequenced in the control command stack. 
An S response causes the next control command to be read. However, if the 
sequence error was due to a SEG command, the Loader aborts.^*" 


OLERR SQ ! IBEGIN WAIT 


There was an incorrect sequence number on a binary record. An S response 
causes the record to be reread.*'*' 


OLERR TA 


No transfer address was encountered in the loading of the root segment. This 
is only a warning message. The Loader sets a default transfer address as the 
first word of the program. 


OLERR UR 


There were unsatisfied references in the path. This in only a warning message. 


TOO MANY dees'" 


There were more DEFs in the Public Library than were allocated at system 




generation. 


This message may be written on DO c 
disk pack. If the alarm occurs, the P 
error is corrected. 


luring writing of the Public Library, LIBSYM, or TVECT table onto the RAD or 
ubiic Library was not completely written and will have to be reloaded after the 


The Loader does not reposition the r 
if they are not repositioned, the next 
tor I/O error recovery procedures pos 
taking of dumps, etc. , before changi 


ecord for rereading. If paper tope or cards are repositioned, the record is reread; 
record is read. If the record is on RAD, disk pack, or magnetic tape, the Moni- 
'tions to the beginning of the next record. However, the WAIT permits the 
ng the environment. 
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8. RAD EDITOR 



INTRODUCTION 

The RAD Editor controls RAD and disk pack allocation by 
generating and maintaining directories for all permanent 
files. Through control command input, the RAD Editor can 

Add or delete entries in permanent file directories. 

Copy data from one file into another. 

Maintain library areas on RADs or disk packs for use 
by the Overlay Loader. 

Copy an object module contained in a library. 

Map file allocation. 

Dump contents of random-access files. 

Save the contents of RADs or disk packs in self- 
reloadable form. 

Clear any permanent area. 

Skip bad tracks v^^hen allocating a file area. 

The RAD Editor generates and maintains directories for the 
following permanent areas: 

System Processor area (SP) 

System Library area (SL) 

System Data area (SD) 

User Processor area (UP) 

User Library area (UL) 

User Data area (UD and Dn) 



The permanent file directories are software write-protected. 
There are four levels of write protection: no protection, 
write permitted byRBMonly, write permitted by foreground, 
and write permitted by background. Write protection for 
files is a user option. Therefore, an SY key-in must be 
initiated before updating or initializing a file directory, 
updating any protected file, or copying data into a pro- 
tected file. 

Space with an area is allocated sequentially, and tracks 
designated as bad are skipped at file allocation. The first 
file in the area begins in the second sector and extends 
over an integral number of sectors. Thus, every file be- 
gins and ends on a sector boundary. When a directory entry 
(and, effectively, its corresponding file) is deleted, the 
area formerly occupied by the file is left unused. In nor- 
mal operation, the RAD Editor makes no attempt to recover 
these unused areas. Therefore, the addition of a file 
may cause overflow of the permanent area although ample 
space may be available. However, RAD squeezing can 
be requested via an Editor !*SQUEEZE command to over- 
come this problem. Squeezing recovers the unused stor- 
age within a permanent area by regenerating the directory 
and moving files. 

Before any permanent file can be written (using the 
Monitor routine M:WRITE), space must be allocated for 
the file. This is accomplished by requesting the RAD 
Editor to add a new entry to the designated directory. 
Control commands allow directory entries to be added or 
deleted. 



DATA FILES 

Ordinarily, data is not written in permanent files by the RAD 
Editor. Data files are normally written by user programs. 
However, a RAD Editor control command con be used to 
copy data from one random-access file to another. Copied 
files may be temporary or permanent files. 



Size and location of each permanent area are contained in 
the RBM Master Directory. The RAD Editor allows mapping 
of all areas, including Checkpoint and Background Temp 
areas, and the dumping of all random-access files. 



PERMANENT RAD/DISK PACK AREA ORGANIZATION 

Every permanent area has its own directory that begins in 
the first sector of the area. The first entry contains the 
address (if any) of the bad tracks within the area. Each 
succeeding directory entry indicates the name, length, 
location, and format of a file in the permanent area. 
Directories are linked; that is, after a sector of a directory 
is filled, the next available sector within the permanent 
area is allocated as the continuation of the directory. 



LIBRARY FILES 

System and User Library files, which are searched by the 
Overlay Loader for external references, are generated and 
maintained by the RAD Editor (the only processor that 
writes in these files). 

A library area (either the System Library area or the User 
Library area) contains six files: 

1. Module Directory File (directory of library modules). 

2. EBCDIC File (list of all library definitions/references). 

3. Extended DEF/REF File (index to extended precision 
definitions/references in EBCDIC file). 
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4. Basic DEF/REF File (index to standard precision 
definitions/references in EBCDIC file). 

5. Main DEF/REF File (index to main definitions/ 
references in EBCDIC file). 

6. Module File (library object modules). 



These files are generated and maintained from information 
in control commands and object modules placed in the 
library by the RAD Editor. Special commands are supplied 
to allow the addition and deletion of object modules; these 
control commands will cause the six files in the RAD Li- 
brary area to be updated. A control command allows an 
object module contained in a library to be copied onto BO. 

Any random-access or sequential-access file (either tem- 
porary or permanent) can be dumped on LO. 

The RAD Editor can save the contents of a permanent area 
and the RBM bootstrap in a self-reloadable form. The 
saved image contains a bootstrap loader, the execution of 
which restores the RBM bootstrap and the permanent area 
on the RAD or disk pack. 

Updating or squeezing of permanent areas and library files 
that contain information for real-time programs must not 
occur while the foreground is using these permanent areas 
or files. The user must ensure that the RAD Editor is not 
modifying a permanent area while a foreground program is 
using it. 



ALGORITHMS FOR COMPUTING LIBRARY FILE SIZES 

The following algorithms may be used to determine the 
lengths of the six files in a library area: 

The number of granules in the MODIR file is 

MODIR =^i^-^ 
n g 



The number of granules in the EDFRF file Is 



EDFRF 



2 + E(2 + r +d ) 
i=l ^ ^ 



wh< 



n is the number of routines in the extended- 

precision library. 

rjl is the number of REFs in the extended-precision 
library. 

di is the number of DEFs in the extended-precision 
library. 

g is the granule size In words. 

The number of granules in the BDFRF file is 



2+L(2 + r, +d,) 



BDFRF 



k=l 



k k' 



wh( 



n Is the number of routines In the single-precision 

library. 

r, is the number of REFs in the kth library routine 

in the single-precision library. 

di is the number of DEFs in the kth library routine 

of the single-precision library. 

g Is the granule size in words. 

The number of granules In the MDFRF file is 



i is the number of modules to be placed in 

the library (including COMMON, extended- 
precision, and single-precision routines). 

g is the granule size in words. 
The number of granules In the EBCDIC file Is 
EBCDIC =i(l±di 



d is the number of unique DEFs and REFs in the 

library (including main, extended-precision, 
and single-precision routines). 

g is the granule size in words. 



MDRFR 



2+XI(2 + r +d) 



wh< 



n is the number of routines in the COMMON library. 

r. is the number of REFs in the jth library routine 

^ in the COMMON library. 

d. is the number of DEFs In the jth library routine 

J in the COMMON library. 

g is the granule size in words. 
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The number of granules in the MODULE file is 



MODULE 



II 



60 , , 

g" ^^i^ 



n is the number of modules in the library (Includ- 

ing COMMON, extended-precision, and single- 
precision routines). 

g is the granule size in words. 



c. 

I 



is the number of record images in the ith library 
routine. 



RAD EDITOR OPERATIONAL LABELS 

The RAD Editor requires the operational labels listed below 
for Input/output. These labels are reserved for use by 
the RAD Editor and must not be used on ! '^DUMP or 
!#FCOPY commands. 



The following labels must be assigned before requesting the 
RAD Editor: 



Label Explanation 



BI Object module Input to System and User 

Library 

BO Output of copies of object modules 

from the System and User Libraries. 

CC Control command input. 

DO Log of control commands, error messages, 

and operator key-Ins. 

LO Maps of directories and dumps of files. 

OC Messages to the operator and key-Ins 

from the operator. 

X1-X6 Assigned and used Internally by RAD 

Editor for RAD maintenance. 



CALLING RAD EDITOR 

The RAD Editor Is requested with a IRADEDIT control com- 
mand. The IRADEDIT control command is read from CC 
and causes the root segment of the RAD Editor program to 
be loaded Into core memory from the RAD. It has the format 

IRADEDIT 



Reading an lEOD from CC causes the RAD Editor program 
to return control to the Monitor. The form of the com- 
mand is 

!EOD 



CONTROL COMMAND FORMAT 

All RAD Editor control commands are Input from CC and 
listed on DO. If CC and DO are assigned to the same de- 
vice, the commands are not listed. The general format Is 



l# 



menmonic specification 



wh( 



I identifies the record as a control command. 

^ indicates that the control command Is unique to 

the RAD Editor. 

mnemonic is the code name of a RAD Editor com- 

mand immediately following the \" characters. 

specification is a series of required or optional 

parameters unique to the specific command. The 
conventions used In specifying parameters are 
(1) a string of up to five decimal digits, having 
a value less than 32,768, denotes a decimal in- 
teger; (2) a string of the form +xxxx Is treated as 
hexadecimal; (3) all other strings are assumed to 
be nonnumerlc. 



One or more blanks must separate the mnemonic and speci- 
fication fields, but no blanks may be embedded within a 
field. An empty parameter in the specification field is 
denoted by a comma. However, commas may be omitted 
for empty trailing parameters. A control command Is 
terminated by the first blank after the specification field. 
If the specification field is absent and a comment follows 
the mnemonic field, the command is terminated by a period. 
The first two characters of the mnemonic portion of the 
command are sufficient to define the command; the re- 
maining characters may be omitted since they are ignored 
if they are present. 



CONTROL COMMAND REPERTOIRE 

ADD The r ADD command adds a new entry to the 

specified permanent file directory. It defines the name, 
write-protection, format, and length of a new file. Adding 
an entry to a directory causes space to be allocated for 



86 Calling RAD Editor/Control Command Format/Con trd I Command Repertoire 



the new file. Once space has been allocated, data can be 
written on the file. The form of the command is 

I *ADD directory, name, file [, record] [, format] 1 



r 



[, write] [, foreground] 



directory specifies a permanent file directory 

(i.e., notBTorCP). It must be a currently 
defined area. 

name is the file name. The file name is composed 

of three to eight EBCDIC characters. If a file 
contains a processor that is loaded with a pro- 
cessor command (!name), the name of the file 
must be identical to the one used in the com- 
mand. Before using the !#LADD, !#LREPLACE, 
and !*LDELETE commands (explained below), 
entries for six special files in the library area 
(SL or UL) must be added. The codes for the 
library files must be one of the following: 



Cod< 



File 



MODIR 


Module Directory 


EBCDIC 


EBCDIC 


EDFRF 


Extended DEF/REF 


BDFRF 


Basic DEF/REF 


MDFRF 


Main DEF/REF 


MODULE 


Module 



For data files, name is determined by the name 
parameter. 

file is the number of records in the file, and must 

be either a hexadecimal value or a decimal 
integer. 

record is the maximum number of bytes per logical 

record and may not exceed 32, 168 bytes. "Rec- 
ord" may be expressed as either a hexadecimal 
value or a decimal integer. The meaning of "rec- 
ord" is determined by the format parameter. The 
record parameter need not be input for library or 
processor files ,'^ since these have predefined 
record lengths. For blocked sequential-access 



For allocating files, if the last character of "directory" 
is P, the file Is a processor file by default; if the character 
Is D, the file Is a data file by default. 



files, logical record size Is 120 bytes by default. 
For blocked compressed sequential-access files, 
the logical record size is 80 bytes by default. 
For unblocked sequential-access files, logical 
record size Is the sector size of the device by de- 
fault. For random-access files, "record" is the 
granule size. The default granule size is the sec- 
tor size of the device, and for random files, granule 
size Is the sector size of the device by default. 

format specifies the structure of the file. It must 
be one of the following codes: 



Cod« 



Format 

Blocked sequential-access file 

Blocked compressed sequential - 
access file 

Unblocked random-access file 

Unblocked sequential-access file 



If omitted, the format parameter Is B for data files 
and R for all library or processor files.' 

write specifies write-protectlon for the file. It 

must be one of the following codes: 

Code Directory 

B Write permitted from background 

F Write permitted from foreground 

N No write protection 

R Write permitted from RBM only 

If omitted, the write parameter Is N for all files. 

foreground is applicable only If "directory" Is UP. 

If "foreground" is F, the named file contains a 
resident foreground task. If "foreground" Is N or 
omitted, the file does not contain a resident 
foreground task. 



DELETE The l*DELETE command deletes on entry from 

the specified permanent file directory. The space formerly 
allocated to the file becomes unused. The space is recov- 
ered if the file being deleted Is the last file in the area. 
The form of the command Is 



PDELETE directory, name 



wh( 



directory specifies a permanent file directory. It 

must be a currently defined file. 
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name is the file name for the entry to be deleted. 

The file name is composed of a maximum of eight 
EBCDIC characters, in which at least one char- 
acter is alphabetic- 



FCOPY The I'^FCOPY (File Copy) command copies data 

from one random-access file to another. The file copy pro- 
cess terminates when an end-of-tape is encountered on 
either the input or the output file. The form of the com- 
mand is 



!#FCOPY oplb^,oplb 



/here 



opib. is the operational label or FORTRAN device 

unit number (e.g. , F:109) of a temporary or 
random-access RAD file. The COPY Utility 
Routine (see Chapter 10) must be used to copy 
sequential-access files. 



opIb. is the input file. 

opib„ is the output file. 



LAOD The I'^LADD (Library Add) command adds an 

object module to the designated library. The object mod- 
ule is read from BI, checked for sequence and checksum 
errors, and stored in the Module File within the library. 
From the data in the object module and on the control com- 
mand, the information about the module is extracted and 
placed in the Module Directory File (MODIR), the EBCDIC 
File, and one of the three DEF/REF Files (either MDFRF, 
BDFRF, or EDFRF File) as indicated in the library param- 
eter. BI may be assigned to any device; if BI is assigned 
to the RAD, it must be a sequential file. The object mod- 
ule on BI must be in Standard Sigma 2/3 Object Language. 
Any blank card or binary card on BI that contains only zeros 
is ignored. The form of the command is 

PLADD directory [, identification] , library 



identification is the program name located in the 

start module item of the object module on BI. 
Within a permanent area (SL or UL), each object 
module must have a unique "identification". If 
the identification parameter is omitted, all object 
modules on BI will be added to the library up to, 
but not including, the file mark or EOD on BI. 

library specifies the target library. It must be one 
of the following codes: 

Code Library 

B Basic Library (single-precision 

math library routines) 

E Extended Library (extended- 

precision math library routines) 

M Main Library (nonmath library 

routines) 



LREPLACE The !#LREPLACE (Library Replace) command 
replaces an object module of the same identification in the 
designated library. The object module is read from BI and 
checked for sequence checksum errors. The object module 
on BI must be in Standard Sigma 2/3 Object Language. Any 
blank card or binary card (on BI) that contains only zeros 
is ignored. The form of the command is 

! ^LREPLACE directory, identification, library 



directory specifies a permanent file directory. It 
must be one of the following: 

Code Library 



SL 
UL 



System 
User 



identification is the program name located in the 

start module item of the object module on BI. 
The object module on BI replaces the module in 
the library having the same identification. 



directory specifies a permanent file directory. 

It must be one of the following codes: 

Code Library 



SL 



UL 



System 



User 



library specifies the target library. It must be 
one of the following codes: 

Code Library 



B 


Basic 


E 


Extended 


M 


Main 
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LDELETE The !#LDELETE (Library Delete) command 
deletes an object module from the designated library. The 
form of the command is 

!$LDELETE directory, identification, library 



directory specifies a permanent file directory. It 

must be one of the following: 

Code Library 



SL 
UL 



System 
User 



identification is the program name of the object 

module to be deleted. 

library specifies the target library. It must be 

one of the following codes: 

Code Library 



B 


Basic 


E 


Extended 


M 


Main 



LCOPY The I^LCOPY (Library Copy) command copies 

an object module from the designated library onto the BO 
device. The form of the command is 

I^LCOPY directory, identification 



directory specifies a permanent file directory. It 

must be one of the following: 

Code Library 



SL 



UL 



System 



User 



identification is the program name (located in the 

start module item) of the object module to be 
copied onto the BO device. 



LSQUEEZE The !$LSQUEEZE (Library Squeeze) com- 

mand will squeeze designated library areas. Unused space 
is recovered by regenerating the directory files and 



squeezing (compacting) the module file. The form of the 
command is 

!#LSQUEEZE directory 



where directory specifies either User Library (UL) or the 
System Library (SL). 



MAP The !*MAP command causes the specified direc- 

tories to be mapped on LO. For each permanent RAD area, 
the beginning and ending RAD addresses for the area are 
mapped. For each file, the contents of the directory entry 
describing the file are printed. This information includes 
name, format, write-protection, foreground task indicator, 
beginning address, EOF address, and EOT address for each 
file. Maps of library directories include program name, 
library designation (Main, Basic, or Extended), and DEFs 
and REFs for each object module. The form of the com- 
mand is 

I'^MAP [directory.] [,dIrectory^]. . . [/directory,] 



wh< 



directory. specifies a file directory. It must be a 

currently defined area. As many as eight direc- 
tories may be Input. 

If no directory parameter is Included, all cur- 
rently defined directories ore mapped. 



DUMP The {''DUMP command dumps a random-access 

file on LO. The file Is dumped one granule at a time. 
The DUMP Utility Routine (see Chapter 9) may also be used 
to dump sequential-access files. DUMP represents each 
word as a four-character hexadecimal number. It dumps 
each granule of the file starting at BOT (if starting address 
Is not specified) and ending at EOT or after the specified 
number of granules has been dumped. The form of the com- 
mand is 



!#DUMP opib [, number 1][, number 2] 



opib is the operational label or FORTRAN device 

unit number (e.g. , F:109) of a temporary, check- 
point, or permanent RAD file to be dumped. 



number 1 is the starting granule address in decimal 

or hexadecimal. 
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number 2 is the number (decimal) of granules to be 

clumped. If the number parameter is omitted, the 
file Is dumped up to EOT. 



SAVE The I^SAVE command saves the contents of the 

RAD for subsequent restoration. The image of the desig- 
nated permanent area (including both directory and files) 
and the RBM bootstrap are written on magnetic tape BO in 
a self-reloadable format; the BO output contains a bootstrap 
loader followed by the RAD images of the RBM bootstrap 
and the designated area. Execution of the bootstrap loader 
causes the RAD image to be read into memory and restored 
onto the RAD without RBM control; after restoration, the 
RBM bootstrap is executed. The BO output can also be re- 
stored on the RAD via the ! ''^RESTORE command (explained 
below). The form of the command is 

!*SAVE [directory^] [,directory ].. . [, directory, J 



CLEAR The !''^CLEAR command zeros out the specified 

RAD area or file. The form of the command Is 



directory- 
saved. 



specifies the permanent RAD area to be 
It must be a currently defined area. 



If no directory parameter is included, all current 
permanent file areas are saved. A request to 
save CP or BT is ignored. 



RESTORE The ! ^RESTORE command restores the perman- 

ent areas saved via a !*SAVE command. It reads the output 
of the !*SAVE command from BI and bypasses the bootstrap 
loader. The form of the command is 



!#RESTORE 



/ 



! #C LEAR directory [, file] 



directory specifies a permanent area. It must be a 

currently defined area. 

file is a file name, within the area specified by 

"directory" which is to be cleared. The re- 
mainder of the area will be unchanged. If "file" 
Is omitted, the entire area is cleared. Note 
that only one area may be cleared with each 
I'^CLEAR command. 



TRACKS The I^TRACKS command will update the list of 

bad tracks for each RAD or disk pack device. This 
list resides in the first sector of each area. The source 
for this update is the existing Alternate Track Pool, 
which is modified via the BT key-in. The form of the 
command is 

!#TRACKS 



END The !*END command is used exactly like the !EOD 

command; that is. It transfers control from the RAD Editor 
to the Monitor. The form of the command Is 

l#END 



This command should be used in place of ! EOD whenever 
multistep job stacks are to be prestored on a file. The 
Utility COPY routine will not interpret this command as 
an EOF. 



SQUEEZE The {'^SQUEEZE command compacts the desig- 

nated file areas. Unused space is regained by regenerating 
the dictionaries and moving files. The form of the com- 
mand Is 

{^SQUEEZE [directory.] [, directory.]. . . [,directory, ] 



directory; specifies the permanent RAD area to be 

compacted. It must be a currently defined area. 

If no directory parameter is included, all current 
permanent areas are compacted. A request to 
squeeze CP or BT is ignored. 



RAD EDITOR MESSAGES 

The RAD Editor program outputs error messages on OC and 
DO. If OC and DO are assigned to the same device, 
duplication of messages on DO is suppressed. If an operator 
response is required, the message 



! IBEGIN WAIT 



is written on OC and DO. The operator activates the con- 
sole interrupt and keys in either of the following codes. 

Code Meaning 

S Continue. 

X Abort RAD Editor and return control to RBM. 
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To abort, the RAD Editor calls the Background Abort 
routine, MrABORT. If the RAD Editor aborts because of 
an irrecoverable input/output error, the code in the abort 
message is the operation label of the device in error. If 
the abort is due to an X response by the operator or some 
error condition, the code Is 'RE'. 



The error messages output by the RAD Editor and their mean- 
ings are given in Table 19. The messages in Table 20 are 
written on the keyboard/printer during RAD restoration via 
the bootstrap loader produced by SAVE. Any error output 
causes the computer to go into a wait state after writing the 
appropriate message. 



Table 19. RAD Editor Error Messages 



Message 


Meaning 


AREA OVERFLOW 


Allocation of the amount of storage indicated by the file parameter on the !"^ADD command 
would cause the permanent area indicated by the directory parameter to overflow. RAD 
Editor reads the next command from CC. 


ASSIGN ERR 


The RAD Editor was unable to assign an operational label to a file because the number of 
available RAD or disk pack device-file numbers is Insufficient. RAD Editor aborts. 


BOT opib 


An unexpected beginning-of-tape has been encountered on the device having the opera- 
tional label opIb. RAD Editor aborts. 


CKSM ERR 


The last record In the object module being read from BI has a checksum error. If the job 
Is ATTENDed, operator response Is solicited; an operator response of S causes the Editor 
to read the next record from BI. RAD Editor aborts. 


CORE OVERFLOW 


The last command cannot be processed for lack of background space. The RAD Editor 
aborts. 


DUP IDENT 


The last object module read from BI cannot be added to the library with a 1"^LADD 
command because it Is already in the library. RAD Editor aborts. 


DUPLICATE NAME 


An attempt was made to add a file whose name already exists for this area. The RAD 
Editor reads the next command from CC. 


EDIT ERR 


Data on the RAD or disk pack has been rendered invalid. RAD Editor aborts. 


EOF opIb 


An unexpected end-of-file was encountered on the device having the operational label 
opIb. RAD Editor aborts. 


EOF READ FILE 


An EOF has been encountered on the Input file. Copying will continue until EOT on 
the Read file or EOT on the Write file Is encountered. 


EOT opIb 


An unexpected end-of-tape was encountered on the device having the operational label 
opIb. RAD Editor aborts. 


EOT WRITE FILE 


An unexpected EOT occurred on the file currently receiving data. This Is a warning to 
the user that the output file Is smaller than the input file (as In !"^FCOPY) but that the 
data already written is correct. The RAD Editor reads the next command from CC. 
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Table 19. RAD Editor Error Messages (cont.) 



Message 


Meaning 


ERR I/O opib 


A calling sequence error occurred for input/output on the device having the operational 
label opIb. RAD Editor aborts. 


FILE OFLO 


A file in the library area has overflowed during execution of a !*LADD command. If 
operator response is S, the next command is read. 


ILLEG BIN 


An illegal binary record (first byte not X'FF' or X'9F') has been read with an obfect 
module on BI. RAD Editor aborts. 


INV CTRL 


Control command is Invalid. It cannot be recognized by RAD Editor or has incorrect 
syntax. If operator response Is S, the next command Is read. 


INV I/O OP opIb 


An invalid input/output operation was attempted on the device having the operational 
label opIb. RAD Editor aborts. 


LENGTH ERRoplb 


A record of Incorrect length was read from or written on the device having the operational 
label opIb. RAD Editor aborts. 


LOAD ERR 


The RAD Editor overlay cannot be loaded. RAD Editor aborts. 


NO BLOCK opIb 


No blocking buffer Is available for the file assigned to the operational label opIb. 
RAD Editor aborts. 


NO IDENT 


The object module on BI does not have the same "identification" In the start module 
Item as Indicated on the I^LADD command, the identification In start module Item is 
blank, or there is no object module on BI. RAD Editor aborts. 


NONEXISTENT FILE 


An attempt was made to delete a file whose name does not exist In the specified area. 
The RAD Editor reads the next command from CC. 


PARAM ERR 


Control command has a parameter error. A parameter has Incorrect content, has been 
omitted, or Is not consistent with the other parameters- A parameter error also occurs for 
duplicate Editor commands; that is, when an already-existing file Is created via the 1*ADD 
command or when a nonexisting file is deleted via the {"^DELETE command. If operator 
response is S, the next command is read. 


RE ERR 


RAD could not be restored completely because either BI Input Is out of sequence, or perma- 
nent RAD areas In the Master Directory do not agree with BI Input. RAD Editor aborts. 


SEQ ERR 


The last record In the object module being read from BI has a sequence error. If the job 
Is attended, an operator response of S causes the Editor to read the next record from BI. 
If the job is not attended, RAD Editor aborts. 


SZ ERR 


The object module on BI cannot be placed in the library because it has more than 61 ex- 
ternal definitions and references. RAD Editor aborts. 
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Table 19. RAD Editor Error Messages (cont.) 



Message 


Meaning 


UNPROTECT RAD 


The RAD or disk pack is write- protected. RAD Editor continues to attempt writing. The 
operator should interrupt and key in SY, reset the appropriate RAD protection switches, 
or interrupt and key in X to abort, whichever is appropriate. 


UNRECOVER I/O opib 


An irrecoverable I/O error occurred on the device assigned to the operational label 
opIb. RAD Editor aborts. 


WRITE PRO opIb 


The magnetic tape assigned to the operational label opIb is write-protected. RAD Editor 
aborts. 



Table 20. RAD Restoration Messages 



Message 


Meaning 


CHCK WRITE ERR 


A check write error occurred (that is, data recorded on the RAD or disk pack could not 
be verified). 


CHECKSUM ERR 


The last record image read has a checksum error. 


RAD WRITE PRO 


The RAD or disk pack is write-protected. 


READ ERR 


The last record being read had a read error. 


RESTORED VXX 


RBM version XX has been restored on the RAD. 


SEQUENCE ERR 


The record images for restoration are out of sequence. 
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9. UTILITY 



INTRODUCTION 

The Utility program operates in the background under the 
Real-Time Batch Monitor. It contains routines that: 

• Copy variable-length binary or EBCDIC records from 
one medium to another (Copy). 

• Dump records onto an output device in either hexa- 
decimal or EBCDIC format (Dump ). 

• Generate or update files that contain Standard Sigma 
Object Language modules (Object Module Editor). 

• Generate or update symbolic files (paper or magnetic) 
that contain source data (Record Editor''^. 

• Edit card images by sequence number (Sequence Editor). 

Routines in the Utility program are device-independent. 
Utility handles any blocked or unblocked, sequential -access 
RAD file. Use of a sequential -access RAD file is similar to 
that of a magnetic tape, as it has a beginning-of-tape, an 
end-of-file (if one has been written), and an end-of-tape. 
Note, however, that a sequential -access RAD file cannot 
be forward-spaced or backspaced over more than one file 
mark. A rewound sequential -access RAD file is positioned 
at beginning-of-tape. For both blocked and unblocked 
files, a record skip is a logical record skip. 



UTILITY PROGRAM ORGANIZATION 

The Utility program consists of two major sections: the Util- 
ity Program Control routine (always resident when the Utility 
program is operating), and the currently operating Utility 
subroutine. The Utility Program Control routine contains 
four interdependent elements: 

1. The Program Executive, which initializes the program 
(upon entry from RBM), interprets the lUTILITY con- 
trol command (explained in "Calling Utility"), exer- 
cises control over the flow of control commands, handles 
normal and abort exits to the Monitor, and performs 

all I/O checking for the Utility program. 

2. The Source Input Interpreter, which reads and scans 
Utility control commands for the Control Function Pro- 
cessor and the current Utility subroutine. 

3. The Control Function Processor, which executes con- 
trol function commands common to all Utility subroutines. 



4. The Operator Communication routine, which outputs 
messages to OC and DO and receives key-in responses. 

UTIUTY EXECUTIVE PROGRAM 

When RBM reads a 'UTILITY control command control is 
transferred to the Program Executive routine. The lUTILITY 
control command is then scanned for parameters. If the 
name parameter is omitted (see "Calling Utility" below), 
it is assumed that only the Control Function Processor will 
be used. Utility control commands are read from the source 
input device (SI). 

If a specific Utility subroutine is requested, the Program 
Executive verifies that the subroutine is in core storage; if 
not, an error message is written and an exit to RBM is taken, 
terminating the background operation. If the subroutine is 
present, initialization of tables and flags occurs. 

The Program Executive then transfers control to the requested 
Utility subroutine. The Utility subroutine uses the Source 
Input Interpreter to read all commands, and uses the Control 
Function Processor to execute control functions. All other 
control commands are interpreted and executed by the Uti- 
lity subroutine itself. 



SOURCE INPUT INTERPRETER 

The Source Input Interpreter, which is called by the Program 
Executive routine, processes all control commands that are 
read by the Utility program. Utility control commands are 
input from the SI device and listed on the DO device as 
they are interpreted. 

Upon reading a command, the Source Input Interpreter de- 
termines whether the command is valid. If the syntax for a 
command is invalid, the following message is written on OC 
and DO: 

INV CTL 
nUKEYIN 



The operator response, either an S to continue or an X to 
abort, determines whether or not the Utility program 
continues. 

If the response is S, the Source Input Interpreter reads the 
next control command from SI. If the command is valid, it 
may be interpreted and executed either by the Utility sub- 
routine or by the Control Function Processor. 



Dump is known as Paper Tape Dump in the BCM system. 



tt 



Record Editor is known as Paper Tape Editor in the BCM 
system. 



CONTROL FUNCTION PROCESSOR 

The Control Function Processor interprets and executes com- 
mands that are common to all Utility subroutines. If any of 
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the control commands interpreted and executed by the 
Control Function Processor contains an invalid operational 
label, the following message is output: 

INV OPLB 
nUKEYIN 



The operator response, either an S to continue or an X to 
abort, determines whether or not the Utility program 
continues. 



OPERATOR COMMUNICATION ROUTINE 

All messages to the operator are written on the OC device 
by the Operator Communication routine. 

If a response is required from the operator, the Operator 
Communication routine types the following message: 

lUKEYlN 



The operator then keys in either an S to continue, or an X 
to abort. 

If the response Is S, a return is made to the calling routine. 
If the operator keys in an invalid response (not S or X), the 
following message is written on OC and DO. 

KEY ERR 
nUKEYIN 



The operator then types in the correct response. 



INPUT/OUTPUT ERROR MESSAGES 

The Program Control routine performs all input/output 
checking for the Utility program. Messages regarding input/ 
output errors are written on both the OC and DO devices. 



CONTROL ROUTINE OPERATIONAL UVBELS 

Four operational labels are reserved for the Program Control 
routine. Their use is restricted to the functions below; they 
may not be used in place of the labels required by the vari- 
ous Utility subroutines explained later. 

Label Explanation 

SI Device for RBM control command input, Utility 

program control commands, and various modifica- 
tion source inputs. 

DO Device for listing of control commands (as they 

are interpreted), messages, error conditions, op- 
erator responses, etc. DO provides a permanent 
log of the control command flow. This is the only 
operational label for the Program Control routine 
that can be assigned to device-file number 



Label Explanation 

DO (i.e., suppressed). If OC and DO are assigned 

(cont. ) to the same device, duplication of messages Is 
suppressed. 

OC Device for messages to the operator, or key-in re- 

sponses from the operator (always via the keyboard/ 
printer). 

X5 Temporary RAD file used for prestoring commands 

read from SI. 

Utility functions are generally executed dynamically; that 
Is, control commands are Interpreted and executed as they 
are read. However, when several operational labels are 
assigned to the same device as SI, It is Impractical to exe- 
cute dynamically. In this case, commands must be pre- 
stored to avoid confusion with data from that device. This 
decision to prestore Is made by the Utility program with one 
exception: when the ! UTILITY command has no name pa- 
rameter, the !*PRESTORE control command allows the user 
the option of prestoring SI Input until an EOD card Image 
Is encountered. For RBM Utilities, prestored commands are 
written on a temporary RAD file (using operational label X5) 
and read from the RAD for interpretation and execution. 



CALLING UTILITY 

The Utility program is requested via a !UTI LITY control com- 
mand, which causes the root segment of the Utility program 
to be loaded Into core memory from the RAD. The ! UTILITY 
control command has the format 

!UTILITY[namej[, parameter] 



name Is the name of a Utility routine or may be 

omitted. It may be any of the following: 

COPY (Copy) 

DUMP (Dump) 

OMEDIT (Object Module Editor) 

RECEDIT (Record Editor) 

SEQEDIT (Sequence Editor) 

parameter represents the series of optional param- 

eters that are unique to each Utility routine. Pa- 
rameters are fully explained in the description of 
the Individual routines. 



When RBM reads a ! UTILITY command, it loads the Program 
Control routine (root segment) from the RAD and transfers 
control to the Program Executive which controls the operation 
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of the Utility program. The Executive first scans the 
! UTILITY control command parameters. If the name pa- 
rameter is omitted, the Executive assumes that the control 
commands that follov\' use the Control Function Processor 
only. If a specific Utility routine is referenced with the 
name parameter, the Program Executive checks the name 
for validity. If the name is invalid, the message 

UT NT RES 

(Utility not resident) is written on OC and DO and the 
Utility program aborts. If the name is valid, the overlay 
segment containing the Utility routine is loaded from the 
RAD, flags ore initialized, and control Is transferred to the 
named routine. 

When the Executive or Program Control routine encounters 
an !EOD card image from SI, it terminates processing. The 
form of the !EOD command Is 



!EOD 



This causes the Utility program to transfer control back to 
RBM. 



CONTROL COMMAND FORMAT 

All Utility program control commands are input from SI and 
are listed on the DO device as they are Interpreted. The 
general format Is 



!*mnemonIc specification 



where 

! identifies the record as a control command. 

* indicates that the control command Is unique to 

the Utility program. 

mnemonic Is the code name of a Utility command 

and begins immediately following the !* characters. 

specification Is a series of parameters unique to 

the specific command. The conventions used In 
specifying parameters are (1) a string of up to five 
decimal digits having a value less than 32, 768 
denotes a decimal Integer and (2) a string con- 
taining more than five characters is always assumed 
to be EBCDIC, regardless of content. 

One or more blanks separate the mnemonic and specifica- 
tion fields, but no blanks may be embedded within a field. 
A control command Is terminated by the first blank after the 
specification field; or. If the specification field Is absent 
and a command follows the mnemonic field, the command Is 
terminated by a period. No control command record may 
contain more than 80 characters. The first two characters 



of the mnemonic portion of the command are sufficient to 
define a control command; the remaining characters may be 
omitted, since they are Ignored when present. 



CONTROL FUNCTION COMMANDS 

The Control Function Processor interprets and executes con- 
trol commands that are common to all Utility subroutines. 
These control function commands are given below. Unless 
otherwise noted, "opib" Is the operational label of the de- 
vice, "number" is the number of file marks or records to 
skip (If omitted, the number is assumed to be 1), and "de- 
vice" Is the device type and physical device number. 

FBACK The !*FBACK command backspaces a magnetic 

tape over a specified number of file marks or a sequential- 
access RAD file to beginning-of-tape (BOT). The form of 
the command Is 



!*FBACK oplb[, number] 



FSKIP The !*FSKIP command spaces a magnetic tape 

forward over a specified number of file marks or a sequential - 
access RAD file over Its end-of-flle. The form of the com- 
mand Is 



A 



*FSKIPoplb[, number] 



MESSAGE The !*MESSAGE command writes messages to 

the operator on the OC and the DO devices. The form of 
the command Is 

!*MESSAGE message 



where message Is any EBCDIC character string up to a full 
card Image. 

The format of the output Is 

! *MESSAGE message 

PAUSE The !*PAUSE command causes a message to be 

written on the OC and DO device followed by a wait for 
the operator's response. The form of the command Is 

!*PAUSE message 



where message is any EBCDIC character string up to a full 
card Image. 

The format of the output is 

!*PAUSE message 
NUKEYIN 
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PRESTORE The !*PRESTORE command causes all control 

commands to be read from the SI device, but not to be in- 
terpreted or executed until an !EOD is read. The prestored 
commands are written on a temporary RAD file (using opera- 
tional label X5) and are read sequentially from the RAD. 
(The prestore mode is set automatically when a name param- 
eter appears on the ! UTILITY command and one or more 
operational labels have been assigned to the satne device 
as SI.) The !*PRESTORE control command must immediately 
follow the ! UTILITY control command and must precede any 
other control commands for the Utility program. The form 
of the command is 



This command will not be interpreted as an EOF when read 
from UI. The form of the command is 



/ 



!*PRESTORE 



REWIND The !*REWIND command causes the specified 

magnetic tape or sequential -access RAD file to be rewound. 
The form of the command is 



A 



!*REWIND opib 



RBACK The !*RBACK command backspaces a magnetic 

tape or sequential -access RAD file over a specified number 
of records. The form of the command is 



!*RBACKoplb[, number] 



If opIb is assigned to a blocked sequential -access RAD file, 
the number parameter is the number of logical records to be 
skipped. 

RSKIP The !*RSKIP command spaces forward the indi- 

cated magnetic tape or sequential-access RAD file over the 
specified number of records. The form of the command is 

!*SKIPoplb[, number] 



If opIb is assigned to a blocked sequential -access RAD file, 
the number parameter is the number of logical records to 
skip. 



UNLOAD The l*UNLOAD command unloads a magnetic 

tape or closes a sequential -access RAD file. The form of 
the command is 

!*UNLOAD opIb 



END The !*END command is treated exactly like an 

!EOD; that is, transfers control from Utility to the Monitor. 
This command should be used in place of !EOD whenever 
multiactivity job stacks are to be prestored on a RAD file. 



A 



!*END 



WEOF The !*WEOF command writes a file mark, EOD, 

or end-of-file pointer if appropriate to the device. The 
form of the command is 



!*WEOF opIb 



ASSIGN The !*ASSIGN command allows a Utility user 

to assign any operational label to any other background 
operational label, device-file number, or RAD file. The 
form of the command is 



1*ASSIGN opIb 



opib 
DFN 
file, area 



DFN is a device-file number. 

file is a RAD file name. 

area is the RAD area within which the RAD file is 

defined. 



COPY ROUTINE 

COPY provides the ability to copy variable-length binary 
or EBCDIC records from cards, paper tape, magnetic tape, 
keyboard/printer, and sequential -access RAD file (blocked, 
unblocked, or compressed) to cords, paper tape, magnetic 
tape, line printer, keyboard/printer, and sequential-access 
RAD file (blocked, unblocked, or compressed). Using con- 
trol functions of the Control Function Processor, records and 
files can be skipped. Output generated by the COPY rou- 
tine can be verified. If the binary mode is requested for 
either copying or verifying, file marks are recognized for 
a magnetic tape or sequential-access RAD file. 

Since COPY uses RBM routines M:READ and M:WRITE for 
all reading and writing, files copied with the COPY routine 
will be treated according to the default conventions of the 
FORM, size, and BIN parameters of the I *COPY command. 
Deviation from inherent conventions is accomplished via 
FORM, size, and BIN parameter options. 



For records being copied to the card punch, records con- 
taining a first byte of X' IC, X'3C', X'9F', X'BF', X'DF', 
X'FF', X'OO', or X'78' are always punched in the binary 
mode; all other records are punched in EBCDIC. For all 
other devices, the distinction between binary and EBCDIC 
modes is meaningless because records are copied directly 
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without translation. Therefore, attempting to copy binary 
data to an EBCDIC device will result in meaningless output. 

For paper tape, if BIN and size are notspecified, the length 
of each binary record (first byte of X'lC, X'3C', X'9F', 
X'BF', X'DF', X'FF', X'OO', or X' 78') is always 120 bytes. 
When M:READ reads EBCDIC records from paper tape, it 
transmits only the number of bytes specified by the calling 
sequence to memory. Ordinarily, the COPY routine assumes 
that paper tape EBCDIC records have a byte count of 120. 
The BIN control card allows the user tooverride the standard 
count. 

By assigning the X4 opib to a RAD file or paper tape device 
before the !*OPLBS command is read, records copied from 
UI are adjusted to a 80- or 120-byte length, depending upon 
the contents of the first byte. 

When copying or verifying a 9-track magnetic tape to a 
7-track magnetic tape, Ul and X4 should be assigned to the 
9T magnetic tape device. 

If a record copied to the line printer or keyboard/printer 
contains more than 132 characters, only the first 132 are 
printed. Normally, the first character of the record is 
printed and single spacing is forced. Therefore, even if the 
first character is intended for format control, it will be 
printed as the first character of the print line in the normal 
mode. If the format option is specified, the first character 
is interpreted as a format control character and is not 
printed. 

The BIN option should only be used to copy nonstandard 
binary records. Since no editing is done when a binary 
read operation is specified, N L, EOM, and / are not inter- 
preted as editing characters. All records are copied on a 
byte-for-byte basis (including leading and trailing blanks). 
EOD is not recognized as a file mark. Therefore, a request 
to copy/ verify one or more files causes input to terminate 
only when the input device goes into manual mode. A re- 
quest to copy/ verify one or more times (when the input de- 
vice is magnetic tape) is processed normally, since file 
marks are recognized. 



COPY OPERATIONAL LABELS 



COPY OPERATING CHARACTERISTICS 

The COPY routine checks whether input/output operational 
labels are assigned to the same physical device. If so, all 
control commands are read from the SI device and stored in 
memory prior to interpretation of the control commands to 
begin copying. When the SI and any input or output opera- 
tional labels are assigned to the same physical device, the 
message 

LD INPUT 
!!UKEYIN 

is written on the OC and DO device, and the Operator 
Communication routine waits for an operator response. The 
operator should load the input at this point and key in an 
S response to initiate the actual copy procedure. 

If the operational labels are not assigned to the same physi- 
cal devices, interpretation of control commands takes place 
as they are read from SI, and copying begins immediately 
without any message being output on the OC device. 



CALLING COPY 

The COPY routine is requested with the control command 
/ lUTILITY COPY[,CORE] 



where CORE specifies that, for the first !*COPY or 
!*VERIFY command, the records from the input device are 
stored in core in addition to being copied or verified. For 
subsequent !*COPYor !* VERIFY commands, these records 
in core, rather than those on the input device, are used as 
the input source. 

After interpretation of the lUTlLITY control command, con- 
trol is transferred to the COPY routine which interprets the 
control commands listed below. 



The following operational labels are used by the COPY 
routine in addition to the Utility subsystem operational 
labels: 



COPY CONTROL COMMANDS 



Label 



UI 



X4 



Device 



Input device 
Verify device 



Other operational labels may be used by COPY (at the op- 
tion of the user) to specify the input and output devices for 
verifying and copying, respectively. 



OPLBS The !*OPLBS command identifies the operational 

labels of output devices to be used in COPY requests and 
input for comparision for VERIFY requests, and must follow 
the ! UTILITY command. The input for COPY operations is 
read from UI. For VERIFY operations, X4 is read. UI may 
not be used as a parameter for COPY operations; nor are 
UI and X4 allowed as parameters for VERIFY operations. 
An !*OPLBS command should follow !*ASSIGN commands 
that change the device type of UI or X4. Operational 
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I abel s may be assigned to any devl ce except a random-access 
RAD file. Assignments remain in effect until anew !*OPLBS 
command is read. The form of the command is 



!*OPLBS oplb^[,oplb2 



][,oplb J 



where opib; is the optional label for an output device for 
subsequent !*COPY commands, or an input device for sub- 
sequent !*VERI FY control commands. The opIb parameter 
may not be assigned to device-file number (n ^8). 



COPY The !*COPY command causes records from the 

input device (UI) to be copied on the output device (speci- 
fied in the !*OPLBS command) until the requested number 
of !EODs or file marks has been read and copied, or until 
the specified number of records has been copied. The form 
of the command is 

!*COPY type [, number] [, FORM] [, size][, BIN] 



wh( 



type is R if the number parameter refers to records, 

or F if the number parameter refers to files. 

number has different meanings, depending upon 

the type parameter that precedes it. If the type 
parameter is R, "number" is the number of records 
to be copied, but refers to logical records for a 
blocked, sequential -access file. If "type" is F, 
"number" is the number of files to be copied, or 
is ALL, indicating that all files should be copied 
until two consecutive EOD images or file marks 
are copied. If "type" is F and any of the input/ 
output devices is a sequential -access RAD file, 
"number" is 1 or it is omitted. If the number pa- 
rameter is omitted, one record or file is copied. 

FORM applies only if data is being copied onto 

the line printer or keyboard/printer. If the FORM 
parameter is omitted, single spacing of printed 
output is the format. If FORM is used, the first 
character of each record is used for format control 
and is not printed. 



size specifies the maximum number of bytes in each 

record. If data is being copied to or from a 
sequential -access RAD file, "size" is the maximum 
logical record size and must be an even number. 
If "size" is omitted, all records are read and written 
in the standard record size (120 bytes). An !EOD 
card will not be recognized by M:WRITE if an odd 
byte count is specified or if a byte count of less 
than four bytes is specified. 



BIN if omitted, mode (BIN or EBCDIC) is determined 

according to byte 1 of the record. If present, all 
copying is done in binary, either with the count 
specified in "size" or the standard record size 
(120 bytes) by default. 



VERIFY The !*VERI FY command requests comparison of 

data on the X4 device with data in core (CORE option) or 
with data from devices specified in the !*OPLBS control 
command. The form of the command is 



! *VERIFY type[, number] [, size] [, BIN] 



The parameters are defined as for the !*COPY control 
command. 

Note: UI must not be used on an !*OPLB command with 
VERIFY. 

Before the !*VERIFY control command is issued, it is assumed 
that all files have been repositioned, if necessary, by use 
of !*REWIND and other file positioning control commands 
(described in "Control Function Commands"). The entire 
verification process is completed when the number of files 
or records for verification has been compared. 



DUMP ROUTINE 

The DUMP routine is used to dump records or files onto an 
output device in either hexadecimal or EBCDIC format. 

DUMP uses M:READ and M:WRITE for all input/output. If 
no mode or the EBCDIC mode is specified for dumping, all 
records are dumped according to the contents of the first byte 
of each record. Any record having a first byte of X'lC, 
X'3C', X'9F', X'BF', X'DF', X'FF, X'OO', or X'78' is 
assumed to be a binary record containing 120 bytes, and is 
dumped with each data word being represented in EBCDIC 
as a 4-digit hexadecimal number. Any record that does not 
contain one of these characters in its first byte is assumed 
to be in EBCDIC and is dumped as such. 

The user has the option to specify the byte count for paper 
tape record input, since M:READ pads all EBCDIC records 
with trailing blanks so that they appear to be fixed length 
in memory. 



The BIN option for dumping should be used to dump non- 
standard binary records. The option causes all records that 
are to be dumped to be read in binary and dumped with each 
data word represented in EBCDIC as a four-character hexa- 
decimal number. Since no editing is done when a binary 
read is specified, NL, EOM, and 9i are not interpreted as 
editing characters. !EOD is recognized as a file mark. 
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DUMP OPERATIONAL LABELS 

The DUMP routine uses the following operational labels: 

Label Explanation 

SI Device for input commands. 

LO Output device for dumping. 

UI Input device for dumping, unless some other 

input device is specified. 

DUMP OPERATING CHARACTERISTICS 

If both SI and DUMP input are assigned to the same device, 
all of the control commands on the SI device are read and 
stored in memory before interpretation of the commands and 
dumping of the input tape begins. When this occurs, the 
message 

LD INPUT UI,ddnn 

nUKEYIN 

is written on the OC and DO device. The operator mounts 
the input tape and keys in an S response to continue. 

If SI and the tape device to be dumped are not assigned to 
the same device, no message is written and control com- 
mands are interpreted as they are read. The DUMP control 
commands are then listed on DO and dumping is performed. 

CALLING DUMP 

The DUMP routine is requested with the control command 
! UTILITY DUMP[,oplb] 



where opib is the operational label of the input devoce. If 
opib is omitted, the operational label is assumed to be UI. 



DUMP CONTROL COMMANDS 

DUMP The !*DUMP command causes records to be read 

from UI and written on the LO device in the specified mode 
until an !EOD or file mark is read, or the specified number 
of records has been read. The form of the command is 



X 



!*DUMP[number][,mode] [, size] 



where 



number is a decimal integer. Only the specified 

number of records is dumped. If "number" is 
omitted, the file is dumped to an EOF or file mark. 



If "number" is ALL, the dump is performed to 
double file marks or !EODs, If the dump "Input" 
(UI) is assigned to a sequential -access RAD file, 
the number parameter must be 1 , 

mode indicates that all records on UI, regardless 

of the content of the first byte of each record, are 
written on the LO device in the mode specified. 
"Mode" is HEX for hexadecimal and EBCDIC for 
EBCDIC. If omitted, EBCDIC is assumed. 

size specifies the maximum number of bytes to be 

read in each record. If the dump "input" is a 
sequential -access RAD file, the size parameter 
must be an even number. Fora blocked sequential- 
access file, "size" is the maximum logical record 
size. If it is omitted, the standard record size is used. 



OBJECT MODULE EDITOR ROUTINE 

The Object Module Editor is designed to maintain files con- 
taining sets of Standard Sigma 2/3 Object Language mod- 
ules. It generates or updates files by inserting and deleting 
object modules according to the program name in the start 
module item for each module. For each output file written, 
a list of module names is printed in the order of their 
appearance. 

Object Module Editor is also used to list files containing 
object modules and to verify that the input object records 
contain no checksum or sequence errors, 

A binary object module is defined as a sequence of binary 
records in Sigma 2/3 Standard Binary format, each of which 
begins with a nonblank name item and terminates with a 
record whose first byte Is X'9F' (END card) indicating that 
the record contains an end item. 

A set consists of one or more object modules and is termi- 
nated by a file mark or !EOD. A tape may contain one or 
more sets and Is terminated by double file marks or !EODs. 
Only one set of object modules can be contained in a 
sequential -access RAD file. 

Note that the Object Module Editor routine does not main- 
tain the object modules in the System Library and User 
Library areas on the RAD. These permanent areas are main- 
tained via the RAD Editor (see Chapter 8). 



OBJECT MODULE EDITOR OPERATIONAL LABELS 

The Object Module Editor uses the following operational 
labels: 

Label Explanation 

BI Device from which binary object modules 

are to be inserted. 

LO Device for listing either UI or UO object 

module names. 
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Label Explanation 

UI Input device. 

UO Output device. 



After entering the modify mode, the Object Module Editor 
operates as foliov^rs: 

If any two of the operational labels SI, BI, and UI are as- 
signed to the same device. Object Module Editor follows 
the steps below: 



OBJECT MODULE EDITOR OPERATING CHARACTERISTICS 

Object Module Editor operates in two modes: list and 
modify. 



In the list mode, -only UI is read. The names of the object 
modules are printed on LO, and the checksum and sequence 
for each record are verified. After interpreting the !*LIST 
control command, the Editor checks if any two of SI, BI, 
and UI are assigned to the same device. If so, the message 

LD UST 

nUKEYIN 



is written on OC. The operator responds by preparing UI 
and keying in an S response. Listing of the modules 
proceeds. 



If no two of the labels SI, BI, or UI are assigned to the 
same device, control commands on SI are interpreted as 
they are read and are written on DO. If the UI device is 
assigned to a sequential -access RAD file, the Object Mod- 
ule Editor leaves the list mode after reading the end-of-fi I e. 



In the modify mode, any modules to be inserted are read 
from the BI device and written on UO, as indicated by the 
SI control commands. If there are input files to be updated, 
they are read from UI. The names of all object modules 
written on UO are listed on LO. The object modules on 
BI must be in the same order in which they are to be in- 
serted on UO. 



1. Interpretation of control commands begins. If any 
object modules are to be inserted, and if SI and BI are 
assigned to the same device, the SI device is read 
until an !EOD is encountered and the message 

LD INSERTS 

nUKEYIN 

is written on OC and DO. The operator loads the mod- 
ules to be inserted on the BI device and keys in an S 
response. If SI and Blare assigned to different devices, 
no message is written. The Editor then reads in all the 
modules on BI until either an !EOD or any other record 
with a first byte different from X'FF' or X'9F' is read 
from BI. Blank records are ignored. 

2. If there are input files to be updated, the message 

LDINPUT 

!!UKEYIN 

is written on OC and DO. The operator must prepare 
UI and key in an S response, 

3. The mode modification control commands are inter- 
preted, causing updating or generation to proceed. 
Each control command is listed on DO as it is interpreted. 

If no two of the operational labels SI, BI, and UI are as- 
signed to the same device, control commands from SI are 
read and interpreted dynamically. Records are read from 
BI and UI and written on UO in response to each mode mod- 
ification control command. Every control command read 
from SI is listed on DO. 



The Object Module Editor operates in the "prestore" mode 
(reading and storing commands before interpreting) when 
the conditions shown below occur; otherwise, the Editor 
operates dynamically. 



Object Module Editor uses M:READ and MrWRITE to perform 
all input/output. Each object module is identified by the 
program name stored in the start module item. No modules 
with blank names are even written on the UO tape. 



Operational 1 
Assigned to S 


.a be 
ame 


Is 
Device 


Prestored Data 


SI, BI 






SI 


SI, UI 






SI 


BI, UI 






BI 


SI, BI, 


UI 




SI, BI 



CALLING OBJECT MODULE EDITOR 

The Object Module Editor is requested with the control 
command 

lUTILITYOMEDIT 
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After interpretation of the iUTILITY control command, 
control is transferred to the Object Module Editor routine. 
The control command and options available to OMEDIT are 
described below. 

Object Module Editor begins reading control commands 
until an !EOD or an !*ENDis read, which terminates 
the SI input. 



OBJECT MODULE EDITOR CONTROL COMMANDS 

LIST The !*LIST command causes the Editor to enter the 

list mode. The names of the object modules on UI are read 
and listed on LO. Any checksum errors detected cause 
error messages to be written on LO, but listing continues. 
If the record is an !EOD, it is listed. If two consecutive 
lEODs are encountered, the Editor leaves the list mode and 
the next control command is interpreted. The form of the 
command is 



INSERT The !*INSERT command causes an object module 

to be inserted and is effective only in the modify mode. 
The form of the command is 

V.NSERTno.a,[,no.e,] 



where 

name. is the name (up to eight EBCDIC characters) 

of the object module to be inserted. 

name2 is the program name (up to eight EBCIDC 
characters) of the last module on UI to be deleted. 
If absent, only one module is deleted. 

The !*DELETE control command must name modules in the 
same order as their occurrence on UI. 



UST 



MODIFY The !*MODIFY command indicates that ob- 

ject modules are to be output on the UO device and causes 
the Editor to enter the modify mode. The modify mode ter- 
minates when an !EOD or !*LIST control command is inter- 
preted from SI, or two lEODs from BI or UI. The form of 
the command is 



'*^^°-^^ [I^ns^rt}] 



^here 



GEN is an optional parameter indicating that ob- 

ject modules are to be selectively input from BI 
and that files are to be generated on UO. UI is 
not read. The control command !*MODIFY GEN 
may be followed only by !*INSERT control com- 
mands (GEN implies !*INSERT) used to define the 
elements to be selectively copied from BI to UO. 
No !*DELETE control commands may be used in 
the GEN mode. 



RECORD EDITOR ROUTINE 

The Record Editor is used for source editing by record num- 
ber from any sequential device to any other sequential de- 
vice. Record Editor provides the following capabilities: 

1. Generates files containing source data. 

2. Lists files containing source images in addition to 
associated line numbers. 

3. Modifies files containing source images. 



RECORD EDITOR OPERATIONAL LABELS 

The following operational labels must be assigned in addi- 
tion to the standard Utility program operational labels: 

Label Explanation 

SI Input device for control commands. 

LO Output device for listing source images. 

UI Input device. 

UO Output device. 



INSERT must be specified if insertions from BI are 

to be read. If BI and UI are assigned to the same 
physical device, the complete BI file (up to an 
!EOD) will be prestored. Modules can be selected 
from BI by names on the !*INSERT control com- 
mands. The inserts must be in proper order. This 
command is used to update (input both !*INSERT 
and !*DELETE commands) UI and to write UO. 

Note: If INSERT and GEN are omitted from the !*MODIFY 
control command, only !*DELETE control commands 
may be input. 



RECORD EDITOR OPERATING CHARACTERISTICS 

The Record Editor routine operates in two modes: list and 
modify. 

In the list mode, the Editor reads source images from UI and 
lists them on the LO device. It associates each image with 
a decimal line number, starting with 1. 

In the modify mode, the Editor either updates or generates 
files on the UO device. 
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Record Editor uses M:READ and M:WRITE to perform all 
input/output. Therefore, all the paper tape editing and 
keyboard/printer editing that is standard to these routines 
is performed. 



CALLING RECORD EDITOR 

The Record Editor is requested with the following control 
command 

! UTILITY RECEDIT 



After interpretation of the lUTILITY control command, con- 
trol is transferred to Record Editor, which begins reading 
control commands. 



RECORD EDITOR CONTROL COMMANDS 

A command requesting either the list or modify mode must 
immediately follow the lUTILITY command. All other con- 
trol commands are interpreted as subcommands under each 
mode. If a binary record is read from UI, the following 
message is written on OC and DO: 

MODE ERR UI,device 

1 ! UKEYIN 



LIST The !*LIST command (list mode) causes the previous 

mode to terminate. The source files are read from UI and 
listed on LO. Each EBCDIC source image is listed along 
with an associated line number up to and including the first 
!EOD source image or file mark read. After the required 
number of files has been listed, another control command 
is read from the SI device. Each !*L1ST control command 
file mark, or !EOD causes the line numbering to restart with 
with 1. The form of the command is 



I* LIST [number] 



where number indicates the number of files to list. Listing 
continues until two consecutive lEODs are encountered or 
the specified number of files is listed. If "number" is omit- 
ted, one file is listed. If UI is assigned to a sequential- 
access RAD file, the number parameter must not be greater 
than 1. 

A !*MODIFY, !*END, or !EOD control command causes 
the list mode to terminate. 



MODIFY The !*MODIFY command informs the Record 

Editor that files are to be either generated or updated. It 



terminates the previous mode and initiates the modify mode. 
The form of the command is 

!*MODIFY [UST][, gen] 



where 

LIST indicates that a listing of records deleted or 

inserted will be produced on LO. If LIST is the 
only parameter used, the listing will contain the 
UI line numbers (the number deleted or the num- 
ber preceding the one inserted). If GEN is also 
present, the UO line numbers will be listed. 

GEN Indicates that records are to be read from SI 

(there is no input on UI) and written on UO. If 
updating is to be performed (that is, there is input 
to be read from UI), the parameter field is I eft empty. 

The modify mode is terminated whenever a !*LIST, 
!*MODIFY, !*END, or !EOD control command is input 
from SI. When the modify mode is terminated and GEN is 
specified, an lEOD or file mark is written on UO. When 
the modify mode is terminated and GEN is not specified, 
the remaining source images of the file on UI (until an EOD 
is encountered) are written on UO, followed by an EOD or 
file mark. 



DELETE The !*DELETE command causes the indicated 

record source images to be deleted and is effective only in 
the modify mode. The form of the command is 



!*DELETE num 



ber^ [, n 



umber„] 



whc 



number] is the line number of the first (or only) 

source image to be deleted. 

number2 is the line number of the last source image 

to be deleted. 



INSERT The !*INSERT command causes record source 

images from SI to be added to UI and written onto UO, and 
is effective only in the modify mode. The form of the com- 
mand is 

!*INSERT number 



where number is the line number that the insertions are to 
follow. If a line number of (zero) is used, the insertions 
will precede the first line. 

Every source image on SI following the !*INSERT control 
command is inserted until a new Record Editor control 
command is encountered. 
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CHANGE The !*CHANGE command causes the indicated 

source images to be deleted, and the source images fol- 
lowing the CHANGE command to be written on UO. The 
command is effective only in the modify mode. The form 
of the command is 

I *CHANGE number, [, number^] 



wh« 



number] is the line num 

image to be deleted 



ber of the first source 



number2 is the line number of the last source 

image to be deleted. If omitted, only one source 
image will be deleted. 

Following the !*CHANGE control command, every source 
image on SI is inserted until another Record Editor control 
command is encountered. 



SEQUENCE EDITOR ROUTINE 

The Sequence Editor edits EBCDIC card images by sequence 
number. It is more flexible than the Record Editor in that 
multiple programs or sections of programs may be updated 
and sequenced individually within single or multiple files. 
It provides greater protection from updating in an incorrect 
sequence, or from accidentally updating the wrong pro- 
gram. Another feature of the Sequence Editor routine is 
that update card images may be inserted without changing 
the existing sequence numbers. Thus, update decks may 
be cumulative and will reflect the development of a source 
program. 

The Sequence Editor is primarily intended for installations 
where EBCDIC source programs are kept on magnetic tape. 
It is somewhat impractical for paper-tape-oriented systems 
or systems without a line printer. 

Editing is accomplished by designating columns 73 
through 80 of a source card image as the "sequence field". 
This field consists of two parts, the ident and the sequence 
number. 

The optional ident is that portion of the sequence field that 
uniquely identifies a program or program segment. If de- 
fined, the ident begins in column 73 of the card image and 
is from one to six alphanumeric characters in length. 

The required sequence number is that portion of the sequence 
field that is sequenced numerically. It consists of from two 
through eight decimal characters and ends in column 80 of 
the card image. The user can specify the value by which 
successive sequence numbers are incremented. In general, 
a large sequence increment will allow larger insertions 
without affecting the existing sequence numbers. 

Together, the ident and sequence number must not total 
more than eight characters. Any unused columns will be 



between the ident and the sequence number and will be 
ignored by the Sequence Editor. 



SEQUENCE EDITOR OPERATIONAL LABELS 

The following operational labels are used by the Sequence 
Editor routine: 

Label Explanation 

SI Update data (includes card images and 

control commands). 

LO Annotated listing of added and deleted 

card images. 

UI Input device. 

UO Output device. 

Device, above, refers to any permanent storage device such 
as magnetic tape, paper tape, or RAD (single sequential 
file). Note that LO should not be assigned to the keyboard/ 
printer, because the sequence number portion of the print- 
out is truncated on that device. 



SEQUENCE EDITOR OPERATING CHARACTERISTICS 

The Sequence Editor performs two separate and distinct 
functions: generates files on UO from source images input 
on SI, and updates files from UI onto UO, taking updates 
from SI, Only one of these functions can be performed per 
call to the Sequence Editor (SEQEDIT). 

The file generation (GEN) function is used to create the 
permanent files initially. It is recommended that files be 
sequenced as they are generated to avoid an update pass at 
a later stage. The user can generate one file (terminated 
by an !EOD or an !*END from SI) wherein a single file mark 
is written on UO, ormultiple files (terminated by two lEODs 
or !*ENDs from SI) wherein two file marks are written onto 
UO and UO is backspaced one file. 

The update function is used to update UI by replacing, 
deleting, or inserting card images from SI and writing the 
updated files onto UO, The files can be resequenced as 
they are written. The user can update one file (terminated 
by an EOF from UI) wherein an EOF is written onto UO, or 
all files (terminated by logical end-of-tape or two EOFs 
from UI) wherein two file marks are written on UO and UO 
is backspaced one file. With the "ALL" option, it is not 
necessary to update each file, but all files will be copied 
onto UO. 

Files can be sequenced as they are generated or updated. 
Sequencing is a separate operation in that the card images 
are sequenced as they are written on UO. Thus, it is pos- 
sible to update an existing file by ident and sequence num- 
ber while placing a new ident and sequence number on the 
updated file. 
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CALLING SEQUENCE EDITOR 



The Sequence Editor is requested via the control command 

/iutilityseqeditQgenILignICall] 



GEN indicates that output files are being generated 

on the UO device and that there are no input files 
to be updated. 

IGN indicates that SI sequence errors are to be 
ignored if UO is being generated or that UI se- 
quence errors are to be ignored if UI is being 
updated. If IGN is used, no sequence error mes- 
sages are printed. 

ALL indicates that the GEN function is to continue 
until two !EOD or !*END cards are encountered 
from SI, or that the update function is to continue 
until two EOFs are encountered from UI. 



sequence number is an integer n2 (2 < n2 < 8) that 

specifies the number of characters in the sequence 
number subset of the sequence field ending in 
column 80. If omitted, sequence number is set 
equal to the difference (8 - ident). 

The user should note that if a nonzero ident field has been 
specified on an !*IDENT command, the idents on each card 
image from UI must match exactly or resequencing will be 
suspended when the first nonmatching ident is encountered. 
Hence, if UI is known to hove nonmatching idents (for 
example, a file that has never been sequenced or one that 
has been updated and contains some blank sequence fields), 
a separate sequence operation should be performed (without 
a simultaneous update) specifying an empty ident field. 

Replacement. The update card itself, rather than a control 
command, is used to replace a card image from UI. The 
sequence number on the update card must equal the sequence 
number on the UI card image to be replaced. The card image 
from UI and the message "DELETED", followed by the card 
image from SI and the message "INSERTED" are output on 
LO. 



The Program Executive transfers control to the Sequence 
Editor, which interprets and validates the parameters. If 
illegal parameters are input, the Utility program aborts 
with a code of UT. If this is an update (the GEN option 
was not specified), the following message is output on OC 
and DO: 

LD INPUT UI, device 

nUKEYIN 



SEQUENCE EDITOR CONTROL COMMANDS 

IDENT The !*IDENT command defines the breakdown 

of the sequence field into the ident and the sequence num- 
ber. It applies to card Images from UI and SI only. If 
used. It should precede the update cords to which It applies. 
If omitted, the ident field is considered empty and the 
sequence number Is eight characters in length. The !*IDENT 
control command is used whenever It Is necessary for the 
Sequence Editor to know the size and content of the ident 
field (that is, when UI contains multlprogram files or 
single-program files with nondecimal characters In the se- 
quence field). It Is not to be used when files are being 
generated. The form of the command Is 



!*IDENT [identjL, sequence number] 



where 



ident is an Integer n] (0 < n] < 6) that specifies 

the number of characters In the ident subset of the 
sequence field starting from column 73. If "Ident" 
is omitted, the ident field does not exist. 



Insertion. The update card Itself, rather than a control 
command. Is used to insert a card image on UO. The se- 
quence number on the update card must be between the 
sequence number of the two continuous UI card I mages where 
the update card Is to be Inserted. The card Image from SI 
and the message "INSERTED" are output on LO. Cards 
without sequence numbers areinserted immediately following 
the sequenced card preceding them. Thus, a large block of 
card images can be inserted by placing the proper sequence 
number on the first card only. The nonsequenced cards will 
be written on the output tape without sequence numbers. It 
is recommended that the tape be resequenced as It is being 
updated If unsequenced cards are inserted. 



DELETE The !*DELETE command deletes one or more card 
Images from UI. Nonsequenced cards can only be deleted 
by deleting from the last sequenced card preceding the non- 
sequenced card(s) up to and including the next sequenced 
card. Deleted card images are listed on LO. The form of 
the command is 



2§. 



40 



!*DELETE [sequence field-] 



sequence field 



wh< 



sequence fleld2 indicates that the Images are to be 
deleted from the Ident and/or sequence number In 
sequence fleldi up to and including the Ident and/ 
or sequence number In sequence field-. 

sequence field ^ contains the Ident and/or sequence 

number of the first or only card Image to be de- 
leted from UI. This parameter Is required. 
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SUPPRESS The !*SUPPRESS command is identical to the 

!*DELETE control command except that no deletion card 
images ore listed on LO. The form of the command is 



73 
-+— 



80 



I *SUPPRESS [sequence fields] 



sequence field 



SEQUENCE The !*SEQUENCE command is used to 

resequence columns 73 through 80 of the card images on 
UO. Only one program can be resequenced with each 
l*SEQUENCE command. Therefore, resequencing is sus- 
pended when either a file mark or a cord image with a 
sequence number identifying a new program is written on 
the output tape. Resequencing is also suspended when 
another !*SEQUENCE command is executed; therefore, 
parts of a program as well as entire programs can be rese- 
quenced. The form of the command is 



73 



80 



> j 1 f 

^^ I ISEQUENCE[seq. field-], increment seq. field. 



where 



sequence field2 contains the Ident and/or sequence 
number of the first resequenced card image to be 
written on the output tape and does not neces- 
sarily have the same fields as defined in the 
I *IDENT command. (The I *IDENT command de- 
fines sequence fields for the input tape and update 
data only.) If omitted, resequencing is suspended. 

increment is the resequencing increment number. 
If omitted, an increment of 10 is used. It is the 



responsibility of the user to ensure that the se- 
quence number does not get incremented past the 
size of the sequence number field. No warning 
is issued if this overlap occurs. 

sequence field] contains the ident and/or sequence 

number from UI at which the !*SEQUENCE 
command becomes effective. If omitted, the 
!*SEQUENCE command takes effect with the 
next card image to be written on UO. 



UTILITY ERROR MESSAGES 

Unless otherwise noted, the following definitions apply in 
error messages given in Tables 21 through 26: 

Code Explanation 

opib Operational label of the device, 

device Device type or physical device number. 

The operator response to NUKEYIN is 

Code Meaning 



Continue 
Abort 



When an irrecoverable error occurs, the Utility program 
aborts. For an irrecoverable input/output error on OC or 
DO, the code in the abort message is the operational label 
of the device. For other operational labels, the irrecover- 
able input/output message is written. Abort returns, due 
either to error or X operator responses, cause UT to appear 
in the abort message. 



Table 21, I/O Error Messages 



Message 


Meaning 


BOT opIb, device !!UKEYIN 


An attempt has been made to backspace over the magnetic tape load point 
or the beginning-of-tape of a RAD file. 


CAL SEQ ERR 


The Utility Executive has encountered a calling sequence error on a return 
from M:READ/M:WRITE, One reason may be an attempt to copy a record 
with an odd byte count onto the RAD (may occur with BCD 7-track tapes). 
See M:READ status returns in Chapter 4 of this manual. 


EMPTY opIb, device ! 1 UKEYIN 


Manual intervention is required (the device is in the manual mode or no 
device is recognized). 


EOF opIb, device !! UKEYIN 


An unexpected tape mark, end-of-file (RAD), or !EOD has been read from 
magnetic tape, cards, paper tape, keyboard/printer, or RAD file. 


EOT opIb, device 1! UKEYIN 


The end-of-tape mark on a magnetic tape or RAD file has been sensed. 
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Table 21. I/O Error Messages (cont. ) 



Message 


Meaning 


IL RAD SEQ opib, device HUKEYIN 


An operational label was assigned to a random-access RAD file, or an 
attempt was made to skip, read, or write more than one RAD file. 


INV I/O OP opib, device HUKEYIN 


An input/output operation is not meaningful for the requested device. 


INV OPLBoplb, device NUKEYIN 


The operational label is not valid. The "opIb, device" portion of the 
message may contain invalid data if input/output is attempted for an 
operational label not recognized by the Monitor. 


I/O ERR opIb, device 


The input/output calling sequence is in error, incorrect length is 
specified, or no input/output is pending for a check operation. The 
Utility program aborts. 


UNRECOV I/O opIb, device HUKEYIN 


An irrecoverable input/output error has occurred after the maximum 
number or retries has been unsuccessfully attempted. 


WRITE PRO opib, device HUKEYIN 


An attempt has been made to write on a write-protected magnetic tape 
or RAD file. 



Table 22. Control Function Command Error Messages 



Message 


Meaning 


FS KIP Command 


DEOFoplb, device HUKEYIN 


Two consecutive file marks were encountered before the required number 
of files had been passed. 


EOT opIb, device HUKEYIN 


The end-of-tape was encountered before the required number of files has 
been passed. 


IL RAD SEQ opIb, device HUKEYIN 


The number parameter is not 1 and "opIb" is assigned to a sequential- 
access RAD file, or the opIb parameter is assigned to a random-access 
RAD file. 


INVOPLB HUKEYIN 


The operational label identifies an invalid device. 


PARAM ERR HUKEYIN 


The opIb parameter is missing, or the number parameter is nonnumeric or 
greater than 32, 767. 


RS KIP Command 


EOF opIb, device HUKEYIN 


An !EOD or file mark was encountered before the required number of 
records was passed. 


EOT opIb, device HUKEYIN 


An end-of-tape was encountered before the specified number of records 
was skipped. 


IL RAD SEQ opIb, device ! lUKEYIN 


The opIb parameter is assigned to a random-access RAD file. 


INVOPLB HUKEYIN 


The opIb parameter identifies an invalid device. 


PARAM ERR HUKEYIN 


The opIb parameter is missing, or the number parameter is nonnumeric or 
greater than 32, 767. 
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Table 22. Control Function Command Error Messages (cont. ) 



Message 


Meaning 


FBACK Command 


BOT opib, device !!UKEY1N 


The beginning-of-tape was encountered before the required number of 
files had been passed. 


DEOFoplb, device MUKEYIN 


Iv/o consecutive file marks were encountered before the required number 
of files was backspaced. 


IL RAD SEQ opib, device HUKEYIN 


The opib parameter was assigned to a random-access RAD file. 


INVOPLB opib, device HUKEYIN 


The operational label identifies an invalid device. 


PARAM ERR HUKEYIN 


The operational label parameter is missing or contains more than two 
characters, or the number parameter is nonnumeric or greater than 32,767. 


RBACK Command 


BOT opib, device HUKEYIN 


The beginning-of-tape was encountered before the requested number of 
records had been passed. 


EOF opib, device HUKEYIN 


A file mark was encountered before the requested number of records had 
been passed. 


IL RAD SEQ opib, device HUKEYIN 


The opib parameter was assigned to a random-access RAD file or a 
compressed EBCDIC RAD file. 


INVOPLB opib, device HUKEYIN 


The operational label identifies an invalid device. 


PARAM ERR HUKEYIN 


The operational label parameter is missing or contains more than two 
characters, or the number parameter is nonnumeric or greater than 32, 767. 


REWIND Command 


IL RAD SEQ opib, device HUKEYIN 


The opib parameter is assigned to a random-access RAD file. 


PARAM ERR HUKEYIN 


The opib parameter contains more than two characters. 


UNLOAD Command 


IL RAD SEQ opib, device HUKEYIN 


The opib [Xirameter is assigned to a random-access RAD file. 


INVOPLB opib, device HUKEYIN 


The opib parameter identifies an invalid device. 


PARAM ERR HUKEYIN 


The opib parameter was missing or contained more than two characters. 


WEOF Command 


EOT opib, device HUKEYIN 


The end-of-tape was encountered. 


IL RAD SEQ opib, device ! lUKEYIN 


The opib parameter was assigned to a random-access RAD file. 


INVOPLB HUKEYIN 


The opib parameter identifies an invalid device. 


PARAM ERR HUKEYIN 


The opib parameter is missing. 
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Table 22, Control Function Command Error Messages (cont. ) 



Message 


Meaning 


PRESTORE Command 


CORE OVFLO 


Available core memory has overflowed. The Utility program aborts. 


PRE ERR IIUKEYIN 


The l*PRESTORE command did not follow immediately after the 
FUTILITY command. 


PRE OVF LO 


The RAD prestore file on X5 has overflowed. The Utility program aborts. 


ASSIGN Command 


ERRFRGD IIUKEYIN 


An attempt has been made to assign a background operational label to a 
foreground operational label, device-file number, or RAD file. 


ERROPLBl nUKEYIN 


The operational label to be assigned is invalid. 


ERR OPLB2 IIUKEYIN 


An attempt has been made to assign one operational label to an invalid 
or undefined operational label or RAD file. 


NO SPARES 1 lUKEYIN 


An attempt has been made to define a new background operational label 
but no room is available in the corresponding table. 


ERR AREA IIUKEYIN 


An invalid RAD area name has been used. 


OPLB TABLE OVFL 1 lUKEYIN 


An attempt has been made to define more than eight unique operational 
labels. The assign will be successful, but the operational label will not 
be used as an output device. 



Table 23. COPY Error Messages 



Message 


Meaning 


CORE OVFLO 


The memory area used for storing input records (when the CORE option on 
the lUTILITY COPY command is used) has overflowed. The Utility pro- 
gram aborts. 


I L RAD SEQoplb, device IIUKEYIN 


An attempt has been made to copy or verify from or to a random-access 
RAD file. 


OPLB TABLE OVFL 1 lUKEYIN 


An attempt has been made to input more than eight operational labels. 
Only the first eight unique labels on an l*OPLB card will be entered 
in the operational label table. 


IDEOF opib, device 
lEOToplb, device IIUKEYIN. 


An end-of-tape, or two consecutive tape marks or lEODs were detected 
on X4 or UI before the number of files requested has been compared. 


EOF opIb, device IIUKEYIN 


An lEOD or file mark was detected on X4 or UI before the number of 
records requested had been compared. 


VERIFY ERR opIb, device 


An error has been found by the verification process. When a verification 
error occurs, the COPY routine terminates execution of the l*VERIFY 
command for that device, but continues verification on other input 
devices. If an error is detected on every input device, the VERIFY 
function is aborted. 
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Table 24. Object Module Editor Error AAessages 



Message 


Meaning 


BLNK NAME oplb^device ! lUKEYIN 


A blank name was input. 


CKSM ERR oplb,device ! ! UKEYIN 


A checksum error was detected on a record read from UI or BI. 


EOT oplb,devlce !1 UKEYIN 


An end-of-tape was encountered on BI or UI. 


ILLEG BIN oplb,device ! ! UKEYIN 


The first byte of a record read from UI or BI did not contain X'FF' 
orX'9F'. 


NO name opib.device ! ! UKEYIN 


Two consecutive lEODs or tape marks on UI, or one !EOD or tape mark 
on BI were encountered during the editing process before the desired 
number of modules had been copied (where "name" is the program name 
not found). 


NO name UI,device 1 1 UKEYIN 


Two consecutive lEODs or file marks (one end-of-file for a sequential- 
access RAD file) are read from UI before the Object Module Editor has 
inserted, replaced, or deleted all requested modules. 


SEQ ERR oplb,device ! ! UKEYIN 


A sequence error was detected in a record read from UI or BI. 



Table 25. Record Editor Error Messages 



Message 


Meaning 


! 1 LD LIST UI,device 


Both SI and UI are assigned to the same device. The operator responds 
by mounting the tape to be listed and changes the state of the device. 


LD INPUT UI,device !! UKEYIN 


The modify mode was entered and updating is to be performed. The 
operator responds by mounting the tape to be input and keying-in an 
S response on OC to continue. 


INV CTRL!! UKEYIN 


A !*MODIFY control command was interpreted from SI when the Record 
Editor was not in the modify mode. 
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Table 26. Sequence Editor Error Messages 



Message 


Meaning 


DELETE ERR HUKEYIN 


No UI card images were found in the block to be deleted (for ! *DELETE 
and ! *SUPPRESS commands). 


DEOF UI,devlce ! ! UKEYIN 


The program to be updated was not encountered on the input tape before 
the logical end-of-tape. An S response causes the Sequence Editor to 
return to RBM. All updating done prior to this point has been written, 
along with the logical end-of-tape marker on the output tape. 


PARAMERR HUKEYIN 


Case 1. Update data from SI contains an illegal sequence number; that 
is, a nonnumeric character. An error alarm is also listed on LO. 

Case 2. A necessary control command parameter was omitted. 

Case 3. The ident parameter (on an l*IDENT card) is greater than 6, the 
sequence number parameter is less than 2, or the sum of the two 
parameters is greater than 8. 


SEQ ERR oplb,devIce !! UKEYIN 


A sequence error was found in either the update data or input tape. In 
this case, the opib parameter refers to either SI or UI. An error alarm is 
also listed on LO. 


UNRECOV I/O UI,device ! ! UKEYIN 


An irrecoverable read error has occurred on UI. The partial card image 
input and the message "UI IGNORED RECORD FOLLOWS xxxxxxxx" 
(when xxxxxxxx is the previous nonblank UI ident and/or sequence 
number) is output on LO. 


UNRECOV I/O UO,devIce ! ! UKEYIN 


An irrecoverable write error has occurred on UO. The card image to be 
output, and the message "UO RECORD OMITTED" or"UO FILE MARK 
OMITTED", are output on LO. 
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10. PREPARING THE PROGRAM DECK 



The following examples show some of the ways program 
decks may be prepared for RBM operaHon. Unless stated 
otherwise, standard default cases for device assignments 
are assumed. 

EXTENDED SYMBOL EXAMPLES 

ASSEMBLE SOURCE PROGRAM, LISTING OUTPUT 
AND BINARY OUTPUT 



Z 



IFIN 



!EOD 



Source deck 
I !XSYMBOLBO,LO 



^ 



IJOB 



In this example, the symbolic input is received from the 
SI device (always defaulted), the binary output is received 
on the BO device, and the listed output is received on the 
LO device. Note that although BO and LO are normally 
default cases, they must be specified if output to the GO 
file (also a default) is not desired. 

ASSEMBLE IN BATCH MODE, LISTING OUTPUT AND 
BINARY OUTPUT WITH SYMBOL CROSS-REFERENCE 



Z 



lEOD 



!EOD 



Source deck n 



^ 



lEOD (optional) 



Source deck 2 



z 



I lEOD (optional) 




Source deck 1 



I IXSYMBOL BA,LO,BO,"cr" 



UOB 




In this example, the source decks are assembled in batch 
mode (BA). In this mode, successive assemblies may be 
performed with a single IXSYMBOL command until a 
double lEOD command is encountered. The parameters 
defined on the IXSYMBOL command will hold true for 
each assembly in the batch. Each assembly will be fol- 
lowed by a Symbol cross-reference (CR). 



ASSEMBLE, LOAD, AND GO FROM USER DEFINED 
OV FILE, LISTING OUTPUT 



IXEQ 



lEOD 



!$ROOT ,,GO, 1 



lOLOAD 



lASSIGN OV=USEROV,UP 



Z 



lEOD 



Source deck 



^ 



IXSYMBOL LO, GO 



IJOB 



lEOD 



! *^ADD UP, USEROV,4, R, N, N 



! RAD ED IT 



•PAUSE KEYIN SYS 



! ATT END 



IJOB 



In this example, the user is defining his own OV file 
through a call to the RAD Editor. After assembly, the OV 
file is assigned to the user defined file. The call to the 
Overlay Loader (lOLOAD) causes it to load the module 
defined on the !$ROOT command to the USEROV file for 
execution. The advantage to assigning the program to a 
user-defined OV file rather than using the RBMOV file is 
that the program can be loaded into core for execution 
repeatedly without reassembly. Conversely, the contents 
of RBMOV cannot be guaranteed to be saved from one job 
to another. 
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ASSEMBLE SOURCE PROGRAM, 
LISTING OUTPUT. LOAD AND GO 



!XEQ 



!EOD 



!$ROOT ,,GO,l 



lOLOAD 



N 



z: 



!EOD 



Source deck 



<> 



IXSYMBOL LO,GO 



!JOB 



_/ 



In fhis example, the binary object module Is loaded Into 
the RBMGO file located In the System Data area. The call 
to the Overlay Loader (lOLOAD) causes It to load the mod- 
ule defined on the !$ROOT command to the RBMOV file for 
execution. The double comma on the !$ROOT command 
Informs the Loader that the temp, exioc parameter options 
are defaulted. The "1" following the GO opib specifies 
that one object module is to be loaded. 



BASIC FORTRAN IV EXAMPLES 



COMPILE MULTIPLE PROGRAMS 



z: 



IFIN 



!EOD 



Source Deck(s) 



IFORTRAN XP 




!EOD 



Source Deck(s) 



^ 



IFORTRAN LO,XP 



[ASSIGN GO=0 






IJOB 



In this example, output to the GO file is not desired in the 
first job, so the GO opIb must be assigned to (see Appen- 
dix E and {ASSIGN command writeup in Chapter 2). An 
object listing is desired (LO) and extended precision real 
data is specified. 

The second job will receive a source listing by default and 
extended precision real data Is again specified. Since the 
parameters are different on the two 'FORTRAN control 
commands, the jobs cannot be run in batch mode. 



COMPILE, LISTING OUTPUT, LOAD AND GO 



Z 



IFIN 



!EOD 



Data deck 




IXEQ 



lEOD 



ISROOT ,,GO,l 



!$ML 



lOLOAD 



lEOD 



N 



Z 



Source deck 







IFORTRAN 



lATTEND 



IJOB 



In this example, the lATTEND command specifies that 
the Monitor is to go Into a "wait" state Instead of 
aborting the job In case of Irrecoverable error (gener- 
ally recommended for "load and go" jobs). Binary out- 
put will be received on both the BO and GO devices 
by default, and standard precision mode is also assumed 
by default. The binary object module is loaded into 
the RBMGO file located in the System Data area. 

Tbe call to Overlay Loader (lOLOAD) causes it to 
load the module defined on the !$ROOT command to 
the RBMOV file for execution. The double comma on 
the !$ROOT command informs the Loader that the temp, 
exIoc parameter options are defaulted. The Loader Is 
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requested to output a LONG map (!$ML). The !XEQ 
command causes the executable program to process the 
data deck. 



SEGMENTED PROGRAM EXAMPLES 

ASSEMBLE SEGMENTED BACKGROUND PROGRAM. 
LOAD AND GO 



COMPILE AND EXECUTE FOREGROUND PROGRAM 

This example would be used for debugging purposes only. 



seg 1 



Root (seg 0) 



seg 2 



seg 3 



IXEQ 



!EOD 



!$ROOT ,+1800, GO 



l$TCB +DB0D,+1200 



lOLOAD ,F 



IPAUSE KEYIN FG,S 






i 



!EOD 



FORTRAN source statements 



^ 



! FORTRAN 



[ASSIGN BO=0 



UOB 



In this example, binary output to the BO device is 
suppressed. The {FORTRAN control command specifies 
that the binary output is to be received on the GO file 
by default and standard precision mode is assumed. The 
IPAUSE command permits the operator to key in FG, S 
to access protected foreground memory. The program is 
defined to the Overlay Loader as a foreground program 
(!OLOAD,F) and the COMMON base is set to the 
FWA of the background. The Loader is to create the 
Task Control Block, the first two words of which are 
defined on the l$TCB command. These two words spe- 
cify that the task is to be connected to interrupt loca- 
tion lOD (Integral interrupt number 2, priority level 8, 
within group 0). 



The l$ROOT command specifies that the root is to be 
loaded from the GO file, and will start execution at 
location 1800 in foreground memory. The core image 
form of the program is loaded on the OV file (RBMOV). 
The IXEQ command loads the executable program into 
core. When loaded, the task is armed, enabled, and 
then triggered. 




Given the program tree structure shown above, the sample 
deck setup illustrates a background program with a root and 
three overlay segments. These are assembled and loaded 
into the RBMGO file. The lOLOAD command specifies 
that these three segments are to be loaded, and defines it 
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as a background program (B). The $SEG commands specify 
that segments 1 through 3 are attached to the root, and the 
modules are to be loaded from the RBMGO file to the 
RBMOVfile for subsequent loading into core for execution. 
A load map is output (!$MP). 



LOAD AND EXECUTE MULTIPLE OBJECT MODULES 



Given the sample program tree structure shown above, the 
illustrated deck would load and execute the segmented 
program. The program is loaded from either the device or 
file assigned to the BI operational label. No load map is 
requested (an l$ML, !$MS, or l$MP command could be 
inserted after the JOLOAD command if a map was desired). 
Although the segments could be loaded in any order, the 
proper calling sequence is the responsibility of the user. 



seg 1 



Root 



seg 2 



seg 3 



Z 



!XEQ 



!$END 



1 Object module 



!$SEG 3,0,BI 



2 Object modules 



X 



!$SEG 2,0,BI,2 



1 Object module 



$SEG5,1,BI 



Z 



Z 



1 Object module 



$$EG 4,T,BI 



1 Object module 



seg 4 



seg 5 




^ 




IZ 




^ 



!$SEG 1,0,BI 



z: 



3 Binary object modules 



^ 



l$ROOT ,,BI,3 



!OLOAD5,B 



IJOB 



RAD EDITOR EXAMPLES 



BUILD PUBLIC LIBRARY 



lEOD 



Relocatable binary module 5 




z 



Relocatable binary module 2 



Relocatable binary module 1 



^ 



!$PUBLIB E,BI,5 



lOLOAD 



lASSIGN OV=PUBLIB,UP 



lEOD 



J/ 



!#ADD UP,PUBLIB,48,0, R, R 



!#ADD SD, LIBSYM, 20, 0, R, R 



IRADEDIT 



! PAUSE KEYIN SY, S 



!JOB 



The Public Library is core resident. In this example, the 
user must create two RAD files to set up the Public Library: 
the LIBSYM file and the PUBLIB file. The LIBSYM file 
contains the Symbol Table for the Public Library and is used 
by the Overlay Loader to satisfy references to the Public 
Library. The PUBLIB file contains the Public Library and 
is booted in with RBM. (RBM must be rebooted to load the 
updated Public Library.) 
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LOAD ROUTINES IN USER LIBRARY 



!#END 



Object module (RMAX ident) 



Z 




!#LADD UL,RMAX,B 



Object module (TUU ident) 



1#LADD UL,TUU,E 



ZZ 



y 



Object module (RDATA ident) 



^ 



!#LADD UL, RDATA, M 



!#ADD UL,MODULE,50,0,R,R 



!#ADD UL,MDFRF,2,0,R,R 



!#ADD UL,BDFRF,2,0,R,R 



y 



!#ADD UL,EDFRF,2,0,R,R 



!#ADDUL, EBCDIC, 6,0,R,R 



!#ADD UL,MODIR,3,0,R,R 



IRADEDIT 



I PAUSE KEYIN SY,S 



!JOB 



In this example, the User Library requires the following 
six files to be allocated in the User Library area (UL): 
MODIR, EBCDIC, EDFRF, BDFRF, MDFRF, and MODULE. 
The !*LADD command enters the routines into the defined 
four files, depending on the library code parameter on the 
I'^LADD command: Basic (B), Main (M), or Extended (E). 
The same basic method is used to set up the System Library. 



UTILITY EXAMPLE 

CREATE A CONTROL COMMAND FILE 

lEOD 



!EOD 



!JOB 



Control command deck 



IJOBC^ 




I *COPY F 



!*OPLBS UO 



I !*AssiGN uo<:cfile,"ud' 



!*ASSIGN UI Sl 



{UTILITY COPY 



l^END 

\ i^ADD UP, CCFILE,5,80,C,N 



IRADEDIT 



IJOB 



In this example, the job stream will create the compressed 
file CCFILE in the User Data area. Control commands will 
be read from the SI device into file CCFILE. The job 
stream on CCFILE may now be executed by assigning 
CC = CCFILE, UD. Note that CCFILE must not have a 
IJOB command on its first entry, since this would imme- 
diately transfer CC back to the SYSGEN assignment. How- 
ever, it is often convenient to end the control command 
file with a IJOB command to initiate a return to the 
SYSGEN assignment. 



A ! JOB command must not be the first card in the Control 
Command deck; IJOBC is permissible. 
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11. SYSTEM GENERATION AND SYSTEM LOAD 



INTRODUCTION 

An RBM sysf-em designed for the requirements of a specific 
Installation Is generated in two phases: SYSGEN (System 
Generation) and SYS LOAD (System Load). These two phases 
create the Monitor and Its required overlays. The SYSGEN 
phase defines RAD allocation or allows the user to override 
the nominal area allocation. 

SYSGEN loads only the specific installation parameters; 
none of the processors are loaded at this time. Its only out- 
put Is an optional, rebootable version of the Monitor. This 
rebootable Monitor Is output on the PM (Punch Monitor) 
assigned device. 

When SYSGEN Is completed, core memory is set up for the 
SYS LOAD function to load the RBM overlays. System pro- 
cessors, user processors, and other user-determined programs 
are loaded onto the RAD by the Overlay Loader or the RBM 
Absolute Loader. 

It Is possible to modify the Monitor and/or Its associated 
processors Individually without going through the entire 
system generation process. Specifically, 

• A new version of the RBM can be written without af- 
fecting the remainder of the RAD. Therefore, reloading 
the entire RAD will not be necessary. 

• Anything on the RAD can be replaced without going 
through a SYSGEN as long as the replacements do not 
exceed their SYSGEN-deflned areas. 

• One Installation can perform a SYSGEN for another 
installation and merely forward a copy of the reboot- 
able RBM binary deck. However, the recipient 
facility will have to perform the SYSLOAD; that Is, It 
will have to load the RBM overlays, the system proces- 
sors, the user processors, and other installation specific 
programs on the RAD. 



SYSGEN 

INITIAL CORE ALLOCATION 

The RBM system Is assembled in two parts. Part 1 is assem- 
bled In absolute and contains SYSGEN (and SYSLOAD), 
and Part 2 Is a stack of relocatable binary decks that may 
be loaded onto the RAD by SYSLOAD. (A list of these 
modules and their corresponding idents is given in Table 20.) 
Part 1 Is loaded by an Absolute Loader (see !ABS control 
command In Chapter 2). Nonoptional resident portions of 
RBM are loaded Into the low core (0K-4K) locations from 
which they will execute; optional resident routines and the 
system generation routines are loaded into high core 
(4K-12K). RBM overlays are loaded at SYSLOAD time. 
The absolute binary deck that Includes all optional routines 
Is initially loaded by the Absolute Loader. 



After this deck Is loaded, the Absolute Loader enters the 
"wait" state. At this point the operator must enter the 
device number of the keyboard/printer into the data 
switches. (The device number used Is that of the keyboard/ 
printer employed by SYSGEN to communicate with the 
operator.) Then the operator may clear the "wait", and 
SYSGEN will continue. 



MINIMUM CONFIGURATION 

The following minimum configuration is required for the 
RBM system generation: 

1. Keyboard/printer. 

2. Minimum of 16K of core storage. 

3. RAD of at least .75M bytes or disk pack. 

4. Protection and memory parity features. 

5. Hardware Interrupts for the RBMControl Task and I/O. 

OPTIONAL ROUTINES 

There are two basic divisions of the optional routines: 
those actually resident at oil times and those functioning 
In the overlay region. All of the routines listed in 
Table 29 function In the overlay region and therefore con- 
tribute essentially nothing to the resident size of RBM. The 
optional resident routines that contribute to the size of 
RBM are as follows: 



Routine 

Power On/Off 
Accounting (Clock 1) 
High-Speed Line 
Printer Handler 
Magnetic Tape Handler 
Multiply/Divide Simulation 
M:IOEX 



Approximate Size 
(decimal) 

196 

216 

79 



208 
175 
188 



The presence of these optional routines Is primarily depen- 
dent on the installation hardware configuration, which is 
partly determined as the device-file Information is input. 
If the Indicated hardware is present, SYSGEN moves the 
optional routines to the resident portion of RBM or set the 
appropriate overlay ident into the overlay table. 
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For example, if a Y response is given for the INC. MUL/ 
DIV.SIM. query, SYSGEN moves the multiply/divide 
simulation package that is included in Part 1 to the proper 
location In core. As another example, if CR4/XX,B is 
typed under the heading DEVICE FILE INFO, SYSGEN 
enters the ident of the card reader error recovery routine 
in the OVrLOAD table. SYSLOAD encounters this ident 
while loading Part 2, singles out the corresponding module, 
and saves it as an overlay on the RAD. 



need additional core space and make the core allocation 
accordingly. A given area could then expand in a future 
SYSGEN, but only the programs in that area would have to 
be reloaded and not the entire system. (In Figure 13, for 
example, the resident foreground might expand into the 
unused Public Library area.) 



Figures 12 and 13 illustrate the core layout both after abso- 
lute load and after SYSGEN and SYSLOAD. 



Debug and the Character-Oriented Communications handler 
operate In the foreground; either a resident foreground region 
or a nonresident foreground area must be allocated If they 
are to be included. 

A method for determining the size of RBM before a SYSGEN 
Is perfomred Is given In Appendix I. 



CORE MEMORY ALLOCATION 



RAD ALLOCATION 

During SYSGEN, the total RAD space is divided into a 
minimum of 1 and a maximum of 20 different areas. Each 
area is labeled with an area mnemonic, usually from the 
following list: 



SP 


UP 


CP 


Dn 


SD 


UD 


BT 


Xn 


SL 


UL 







Core memory Is allocated In the following manner (see 
Figure 10): 

1. The first 256 words In lower memory (the zero table) 
are reserved for a communication region (see Table 1). 

2. The region from (decimal) 256 to 399 Is reserved for 
internal and external interrupt levels; any space not 
required for interrupt levels will be used by the 
Monitor for table space. 



where n is a hexadecimal digit. 

Areas are allocated by tracks, so the actual size of an area 
Is dependent on the type of RAD device. The various track 
sizes are given below: 



7202/4 

7232 

7242 



2880 words 

6144 

3072 



3. The remainder of core will be allocated by SYSGEN 
as follows: 

a. Resident RBM, to be loaded beginning at location 
400 (decimal) and to include only optional routines 
selected by SYSGEN. 

b. Public Library (if allocated). 

c. Resident Foreground (if allocated). 

d. Nonresident Foreground (if allocated). 

e. Background, at least one page whether or not 
required; minimum amount allocated should be 
lengthof the Job Control Processor (3500 locations, 
decimal). See Figure 11. 

4. No foreground space need be allocated for a batch- 
only system. 

When all user inputs necessary to calculate the exact size 
of the resident RBM are made, the ending address of 
RBM will be output by SYSGEN. The user will then input 
starting addresses for the Public Library, the resident fore- 
ground, the nonresident foreground, and the background. 
The user should decide which of these areas are more apt to 



If the first area allocated to each RAD Is not preceded by an 
SK (skip track) Input, the system bootstrap will be written 
in sector 0, and the area will actually begin at sector 1. 
All other areas, with the possible exception of the BT area, 
will always start on a track boundary. The five areas 
described below may receive default allocations. During 
RAD allocation, the user must specify a system RAD to 
receive the default areas. An SK Input as the last input on 
the system RAD will be Ignored If default allocations are 
to be made. 

The areas that may be default allocated and their sizes are 

SP Only large enough to contain RBM overlays 

and all standard processors (see Table 6). This 
is the only mandatory area. 

SD Only large enough to contain nominally large 

RBM GO and RBM OV files and other small 
files (i.e., RBM S2, RBM ID etc.). 

SL Only large enough to contain the standard 

system libraries: standard precision, extended 
precision and common, or main libraries. 

CP Only large enough to contain all of 

background. 
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(KrPLFWA) 
(KrRFFWA) 

(KrNFFWA) 

(KrBACKP) 
(KrBACKBG) 

(K:UNAVBG) 






Low Core 






i 


External/Internal Dedicated Interrupt Locations 
Zero Table: Constants and Pointers 


RBM 


Resident RBM 


Selectable, optional RBM Routines 


I/O tables for RBM 


Transfer Vector Table 


Public Library 




Real-time task *1 temp stack 


Resident 

Foreground Program *1 


Task Control Block #1 


C 

u 

K 

1 


u 

3 


Real-time task ^\ 


o 


Real-time task *2 temp stack 


c 

u 


' 


Task Control Block #2 


Real-time task #2 


Special end-action I/O routine 


Foreground program "^1 COMMON 


• 


Additional Resident 
Foreground 


Real-time task *N temp stack 


Nonresident 
Foreground Space 


Task Control Block #N 


Real-time task *N 


Background TCB 




1 


Background temp stack 


Background Program 


User main program 


u 

IXJ 

1— 

o 


User subprograms 


1 


7 

5 


Library subprograms 


Blank COMMON (if any) 






High Core 





Figure 10. RBM Core Memory Allocation Example 
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Low Core 



High Core 



Background TCB, without PSD 
(In protected memory) 



Floating accumulator (5 locations) 



FORTRAN I/O Format Information 



Allocated temporary space 



Unallocated (as yet) temporary 
space for Public Library Use 



User Program and subprograms 
(Including any library routines 
not in the Public Library) 



Unused core 



RAD I/O Blocking Buffers 
(From 1 to 16 buffers; size of 
buffer determined at SYSGEN) 



Blank COMMON (if any) 



(Unavailable Memory) 



(KrBACKP) 



(K:BACKBG),(K:BASE) 



TEMPBASE+6 



K:DYN 



TEMPLIM 



(KiBACKBUF) 



(K:UNAVBG) 



Figure 11. Background Core Allocation Example 
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RBM Zero Table 




RBM Resident Routines 


RBM Optional Resident Routines 
and Tables 


RBM SYSGEN 


RBM SYSLOAD 


RBM Optional Nonresident 
Routines 


TVECT Table 









BT 



Figure 12. Core Layout After Absolute Load 



RBM Zero Table 



Interrupt Locations (Unused Interrupt 
Locations Used by RBM Tables) 



RBM Resident Portion 
(Nonoptional Routines) 



RBM Overlay Region (512 Words) 



RBM Resident Region (Optional 
Routines) 



Unused RBM Area 



Transfer Vector Table for 
RBM and Public Library 



Public Library 



Unused Public Library Area 



Resident Foreground 



Unused Resident Foreground Area 



Nonresident Foreground 



Unused Nonresident Foreground Area 



Background (RBM Overlay Area for 
JCP) 





100 

190 



High Core 



Remaining RAD space. The last track avail' 
able for the default assignment of this area is 
device specific, as follov/s: 

Device Last Track Available + 1 



7202 


123 


7204 


506 


7232 


506 


7242 


4000 



Figure 13. Core Layout After SYSGEN and SYSLOAD 



For all devices except a 7242, all available tracks may be 
allocated. Tracks at the upper end of the device are used 
as alternates for bad tracks within an area. The RAD allo- 
cation at SYSGEN constructs the Master Dictionary, con- 
sisting of four words per entry. The only restrictions are 
that each area mnemonic must be alphanumeric, the size of 
the Master Dictionary may not be exceeded, and if an area 
is allocated twice, the space originally reserved will be 
lost. 



FILE CONTROL TABLE ALLOCATION 

The File Control Table (FCT) is indexed by device-file 
number and contains information about oil device-files in 
the system. The total size of the File Control Table is 
determined and allocated at SYSGEN time. The term 
"device file number" (DFN) indicates the order in which 
devices are defined. For example, since the first device 
defined must always be a keyboard printer; DFN 1 will al- 
ways specify a keyboard printer. Devices other than the 
RAD have permanent device-file number assignments made 
at SYSGEN time. SYSGEN allows room for up to 50 per- 
manent device-files (not including RAD files). 

A separate device-file (i.e., FCT entry) is required for 
each open file on the RAD. Hence, the total number of 
entries necessary in the File Control Table for all RAD files 
is the maximum number of simultaneous open files. At 
SYSGEN time, the user must specify this maximum number 
of device-files for his foreground programs. For the back- 
ground, nine device-files will be allocated (a sufficient 
number for the system processors), if the user does not 
choose to override the default case. 

SYSGEN always allocates three foreground RAD files for 
use by the Monitor in addition to the number of RAD fore- 
ground files input by the user. Hence, the total size of the 
File Control Table will be the sum of the number of non- 
RAD files assigned, plus the total number of RAD files re- 
served for foreground use plus three, plus the number of 
RAD files reserved for background use (nine, if none are 
explicitly reserved). 

The user can make file dictionary entries on the RAD for 
his foreground programs and then permanently allocate a 
foreground device-file number to that RAD file by assigning 
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the RAD file to a foreground operational label. A device- 
file number reserved for background use is assigned by the 
Monitor service routines M:DEFINE and M:ASSIGN when- 
ever a call is made to either of these routines. For RAD 
device-files, SYSGEN allocates the appropriate space in 
the File Control Table and sets the background/foreground 
Indicator, the "file for RAD use" indicator, the maximum 
retry counter, and the pointer to the I/O Control Table. 
For non-RAD files, SYSGEN sets in the File Control Table 
the background/foreground indicator, the channel number, 
the device type number, the "file for non-RAD use" indi- 
cator, the device number, the maximum retry counter, and 
the pointer to the I/O Control Table. 

SYSGEN also allocates space for the I/O Control Table. 
The amount of space required for each type of device is 
contained in the Device Type Table. 



OPERATIONAL LABEL ASSIGNMENTS 

During SYSGEN the user specifies the selected standard 
operational labels and assigns each to a device-file num- 
ber (other than a RAD file number) or to device-file zero. 
These assignments v/ill be maintained as permanent assign- 
ments for the appropriate operational label. 

The operational labels listed belov/ are normally associated 
with RAD files. Therefore, permanently assigning these 
labels to non-RAD files at SYSGEN time is not permitted. 



Operational 
Label 



RM 



ML 



PI 



OV 

XI-X5 

S2 

GO 



Use 

Used by RBM to load the RBM overlays 
and is reserved exclusively for RBM. 

Used by M:LOAD to load nonresident 
foreground programs. 

Should be used by any background program 
with overlays to load the overlay segments 
from the RAD. For system processors, PI 
is assigned to the processor file. For back- 
ground programs loaded with an XEQ com- 
mand, PI is assigned to OV. Foreground 
programs must specifically assign an opera- 
tional label to the file from which overlay 
segments are to be read. 

Normally assigned to the RBMOV file for 
"assemble and go" type operations. 

Processor scratch files. 

XSYMBOL standard procedures. 

Normally assigned to the RBMGO file 
for "assemble and go" type operations. 



After all inputs are made by the user, SYSGEN allocates 
three additional entries in the Foreground Operational 
Label Table for RAD foreground labels. 

A total of 100 operational labels can be allocated and 
assigned at SYSGEN time, including those automatically 
allocated by SYSGEN. 



INPUT PARAMETERS 

When RBM is loaded and control is transferred to the 
SYSGEN routine, operator intervention is required to input 
the system parameters. The following device types are 
standard and must be referred to by name when inputting 
the device-file definitions: 



SYSGEN Device 
Type Name 

KP 
M9 
PT 
M7 

B7 

RD^ 
XX 

LP2 
LPS 
CR4 

BR4 

CP3 
BP3 

CPl 



Device Characteristics 


Device 
Name 


Keyboard/pri nter 


KP 


Magnetic tape, 9-track 


MT 


Paper tope handler 


PT 


Magnetic tape, 7-track, 
packed binary option 


MT 


Magnetic tape, 7-track 
BCD option 


MT 



RAD or disk pack RD 

Spec la I -purpose device for 
use with M:IOEX 

Line printer, 240 Ipm LP 

Line printer, 800 Ipm LP 

Card reader, EBCDIC option, CR 
1400 or 400 cpm 

Card reader, BCD option, CR 

1400 or 400 cpm 

Card punch, 200 cpm CP 

Card punch, BCD option, CP 

200 cpm 

Card punch, EBCDIC CP 

option, 100 cpm 



RD is used only to reserve a specific number of foreground 
or background RAD files, not as a name of the form dtnn. 
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SYSGEN Device 

Type Name Device Characl-eri sties 



BPl 
PL 



Card punch, 100 cpm 
Graphic plotter 



Device 
Name 

CP 
PL 



RBM supports the graphic plotter as a device type but will 
not do any special converting or formatting. The user can 
either use the existing library routines to format data for 
the plotter or perform his own formatting. 



The Run-Time names are used by M:READ/M:WRITE for op- 
erator communication. 

Table 27 defines the system parameters that are input via the 
keyboard/printer, paper tape reader, or card reader during 
SYSGEN. Note that all numeric entries can be input in 
either decimal or hexadecimal with leading zeros ignored; 
all hexadecimal entries must be preceded by a +. Comments 
can be added to any input by leaving one space after the 
required input is made. All inputs from the keyboard/printer 
must terminate with a NEW LINE code. Commas are used 
to separate fields. If an input/output device is not in the 
START state, an appropriate message will be written on the 
keyboard/pri nter. 



Table 27. SYSGEN Input Options and Parameters 



Output Message 


Input Parameters 


Description 


!1 RBM SYSGEN 
INPUT DEVICES 


Device Name and Number 
(e.g.,CR4/03,LP8/02;KP, 
NO;PT20,KP) 


Device name and device number of the input and 
output devices to be used during SYSGEN. If the 
keyboard/printer is to be used exclusively, only KP 
need be Input. The only acceptable device names 
are CR, LP, KP, PT, or NO. 


VERSION 


Two alphanumeric characters 
(e.g., Al or A2 or Bl, etc.) 


The RBM version will be stored in a zero table lo- 
cation, KrVRSION, output by RBM on LL at the 
start of each job and by postmortem dump whenever 
it runs. 


MEMORY SIZE 


Numeric size 


Total core memory size of Sigma 2/3, stored in a 
zero table location, K:UNAVBG. 


MAX. INT. LOC. 


Address 


Maximum Sigma 2/3 address for real-time external 
Interrupts (263 < A < 400).^ The space unused by 
the interrupts will be allocated to RBM tables by 
SYSGEN. 


CONTROL TASK INT. LOC. 


Address 


Address of interrupt used by RBM Control Task. Must 
be the Interrupt with the lowest priority available. 


INT. CHANNELS 
EXT. CHANNELS . 


X - y or 


Indicates the numbers of the I/O channels specific 
to this Installation, x Is the first channel number, 
and y is the last number. If no channel exists for 
this lOP, a Is input. Sigma 2, for example, would 
always have an input of for EXT. CHANNELS. 
The number of channels must be greater than four but 
less than 20 for Sigma 2 (less than 28 for Sigma 3). 
For Sigma 3, through X'B' are the Internal chan- 
nel numbers and X'C through X'lB' are the exter- 
nal channel numbers. 


Although Sigma 3 has provisions for interrupt locations only as high as 368, 400 is considered to be the beginning of 
operating RBM for compatibility with Sigma 2. The 32 extra cells are used for Input/output tables. 
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Table 27. SYSGEN Input Options and Parameters (cont.) 



Output Message 


Input Parameters 


Description 


NO. LINES/PAGE 


Number 


Number of lines to be printed on each page during 
an Extended Symbol assembly. SYSGEN will save 
the input value in zero table location KrPAGE, for 
later use by Extended Symbol in printing out a title 
at the top of each page. Input value n must be 
< n < + 8000. 


NO. DEFS IN PUB. LIB. 


Number 


Number (n < + 100) of definitions (DEFs) in the 
Public Library. This input Is needed so that the 
Transfer Vector Table can be correctly allocated. 
If zero is input, SYSGEN assumes there is no 
Public Library. 


NO. ENTRIES IN 
NONRES. FGD. QUEUE 


Number 


Reflects the maximjm queue size for nonresident 
foreground programs. 


NO. FGD PARITY ERRS 


Number 


Number of parity errors to allow in foreground 
before disabling the foreground task. 


NO. DICT. ENTRIES 


Number 


Specifies the length of the Master Dictionary. 
Entries are already allocated for SP, SD, SL, CP, 
and BT. A number from to 15 may be input, 
specifying the additional Master Dictionary entries. 
Each entry requires four words. 


ALT. TRK. POOL SIZE 


Number 


Specifies the length of the Alternate Track Pool, 
which will contain bad track numbers. It should 
be at least as large as the maximum number of 
known bad tracks. The bounds are to 512. 


RAD ALLOCATION 


RDxx/dn / p /S 

(for example, RD42/E1,S) 


XX specifies the device type as follows: 

02 7202 

03 7203 

04 7204 
32 7232 
42 7242 

dn is the hardware device number for this RAD, 
which must be driven by a channel defined 
previously under "INT CHANNEL" or "EXT 
CHANNELS". Each device can only be input 
once, but as many as 12 devices, each with area 
allocations, may be input. I or E specifies the lOP 
type; I refers to an Internal lOP, and E to an External 
lOP. E is assumed for a 7242 or 7246 and is the de- 
fault case for a 7232. lorE must be input for a 720x. 
If this parameter is not used, an intervening comma 
before the next parameter is not necessary. 

S indicates that this device is to receive default 
allocations. If more than one S parameter is input 
the last is used. If S is not input, the device re- 
ceiving the SParea is used. Either S or the SParea 
must be input. 
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Table 27. SYSGEN Input Options and Parameters (cont. 



Output Message 


Input Parameters 


Description 


RAD ALLOCATION (cont.) 


yy =zz 

For example: 

SP = 30 
SD*=20 
Dl = 100 
D2 = 200 


yy is any area mnemonic, usuallyfrom the following 
list 

SP UP BT Dn 
SD UD CP Xn 
SL UL 

where n is a hexadecimal digit. 

zz is the number of tracks to allocate for area yy. 
If zz =0, area yy will be undefined, and an 
additional Master Dictionary entry will be available. 
If zz = ALL, the area will occupy the remainder of 
the RAD and no other inputs may be made for this 
RAD. If yy = SK, zz number of tracks will be skipped 
before the next area is allocated. But to be mean- 
ingful, another area must be Input. If the first 
input is not SK = zz, this RAD will receive a system 
bootstrap in sector and the next area will actually 
begin in sector 1. If no orders are allocated on 
RAD dn, however, no bootstrap will be written. 


END 


Terminates the RAD ALLOCATION parameter. 

In the example given, areas SP, SD, Dl and D2 
will receive the number of tracks specified. SL, 
CP, and BT will be default allocated, (as described 
under RAD ALLOCATION) on this same device. 


BUFFER SIZE 


180 or 512 


Specifies the blocking buffer size for all Monitor 
blocked files In this system. 


INC. POWER ON/OFF 


Yor N 


Yes (Y), if Power On/Power Off routine Is to be 
included in resident RBM. 


INC. MUL/DIV. SIM. 


YorN 


Yes (Y), If multiply/divide software Is to be in- 
cluded. If multiply/divide hardware exists. 
No (N) should be input. 


INC. M:IOEX 


Yor N 


Yes(Y), if optional RBM service routine MrlOEX 
is to be included. 


INC. CLOCK ONE 


YorN 


Yes (Y), if Clock 1 is to be used by RBM for job 
accounting, for limiting the execution time of 
background jobs, for time limits on I/O transfers, 
and for keeping time of day. If No (N) Is input. 
Clock 1 is not available and SYSGEN will not load 
the fob accounting portion of the RBM Control Task. 


INC. DEBUG 


YorN 


Yes(Y), if RBM Debug is to be included. If Debug 
is Included, at least 200(16) foreground cells must 
be allocated and Debug I/O devices may be input 
below, under DEVICE FILE INFO. If No (N) is 
input. Debug will not be loaded and the user can 
use the 32 zero table Debug cells as additional 
foreground mailboxes. 
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Table 27. SYSGEN Input Options and Parameters (cont.) 



Output Message 



Input Parameters 



Description 



INC. MISC. 



Yor N 



Yes(Y), if the non-Debug Core Dump, RAD Dump, 
and Hex Corrector routines are to be Included in 
RBM. If Y response is given, the resident size 
of RBM will increase by 85(]0) cells. 



INC. C.O.C. 



Yor N 



Yes (Y), if Character-Oriented Communications 
Handler is to be included. If COC is included, at 
least 1000 cells must be allocated for resident 
foreground. 



DEVICE FILE INFO. 
[(INC. DEBUG)] 



dtnn,x , 



RD,x,y 



The first parameter, dt, specifies a certain pe- 
ripheral and must be one of the device type names 
listed previously under "Input Parameters". The 
second parameter, nn, is the hardware device 
number of this peripheral and must indicate a pre- 
viously defined channel. The third parameter, x. 
Is F if this is a foreground device, B if this Is a 
background device, DI if this is a Debug input 
device, or DO If this is a Debug output device. 
(DI and DO will not be accepted if an N (no) re- 
sponse was given to the INC. DEBUG message.) 
The last parameter, I or E, is required to Indi- 
cate lOP type for a multiunit device; I indicates 
an Internal lOP, and E indicates an external lOP. 
The last parameter is ignored if the device is not a 
multiunit type. 

The first device-file entry, DFN 1, must be KPnn, F. 
The term "device-file number", abbreviated as DFN, 
indicates the order in which device parameters are 
input in response to the DEVICE FILE INFO, output 
message. 



This entry indicates to SYSGEN that y RAD File 
Control Table entries are to be saved for the mode 
specified by the parameter x (same as x above, ex- 
cept that DI and DO cannot be used). The y pa- 
rameter may be one or two decimal digits. An entry 
must always be input for the foreground, and a 
default number of 9 is used for background files if 
a user fails to allocate any background file. (Thus 
if no input is given, SYSGEN will reserve nine 
background RAD file entries. ) The value 9 is always 
added to the background allocation. 



Examples: 




DFN No. 


Device-File 


1 


KP40,F 


2 


LP8/02,B 


3 


CR4/03,B 


4 


CP1/04,B 


5 


PT20,B 


6 


BR4/03,B 


7 


M9D0,B,E 


8 


M9D1,B,E 


9 


M7E0,B,E 
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Table 27. SYSGEN Inpuf Options and Parameters (cont.) 



Output Message 


Input Parameters 


Description 


DEVICE FILE INFO. 
[(INC. DEBUG)] 
(cont.) 


RD,x,y (cont.) 


Examples: 

DFN No. Device-File 

10 B7E0,B,E 

1 1 LP2/05,F 

12 CR4/03,F 

13 M9D0,F,E 

14 M9D1,F,E 

15 XXDO,F 

16 LP8/02,D0 

17 CR4/03,D1 
18-27 RD,B,10 
28-46 RD,F,20 

END 


END 


Signifies end of device-file information. 


BCKG. OP. LBL. 


Operational label = device- 
file number, or device unit 
number =device-file number 
(one per line, terminated by 
END); = n means reserve n 
locations in Operational 
Label Table for temporary 
assignments. (Temporary 
space is needed for execution 
time temporary assignments, 
or for RAD files above and 
beyond that number (9) which 
is automatically allocated 
by SYSGEN). 

Examples: 

SI=3 

102=4 

= 3 (reserves three addi- 
tional entries in Op- 
erational Label Table) 


Background operational labels or device-unit number 
and device-file number equivalents for permanent 
I/O assignments. No operational labels can be 
assigned to RAD files at SYSGEN time. A maximum 
of 188 background and foreground operational labels 
can be input by the user. The following operational 
labels are defined by RB7; thus, they may not be 
input: 

RM OV 
ML GO 
PI 


END 


Signifies end of background operational label. 


FGD. OP. LBL 


Same as for background, ex- 
cept that space for three 
operational labels is auto- 
matically assigned. 


Foreground operational labels or device unit number 
and device-file number equivalents for permanent 
foreground I/O assignments. No foreground opera- 
tional labels can be assigned to RAD files at 
SYSGEN time. 


RBM LWA = + xxxx 


None 


At this point, SYSGEN will have sufficient infor- 
mation to calculate the exact size of RBM. This 
message is output to the operator as an aid in the 
follow-on inputs. If the user has only background, 
he will have to input an address for the start of the 
background (i.e. , at least 38 cells greater than the 
RBM LWA output). This value (i. e. , + xxxx) can 
be predetermined by using the algorithm given in 
Appendix L. 
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Table 27. SYSGEN Input Options and Parameters (cont.) 



Output Message 


Input Parameters 


Description 


PUB. LIB. FWA^ 


Address 


If zero has been input for the number of DEFs in the 
Public Library, this typeout will not occur. Other- 
wise, the input should reflect the first word address 
of the Public Library (which may be equal to RBM 
LWA). An input of zero is illegal. This value is 
stored in zero table location K:PLFWA. 


RES. FGD. FWA^ 


Address 


First word address of the resident foreground area. 
An input of zero indicates no resident foreground. 
This value is stored in zero table KrRFFWA. 


NONRES. FGD. FWA^ 


Address 


First word address of nonresident foreground area. 
An input of zero indicates no nonresident foreground. 
This value is stored inzero table location K:NFFWA. 


BCKG. FWA^ 


Address 


First word address of background memory. This ad- 
dress must start on a page boundary (some multiple 
of 100|^). This value is stored in zero table loca- 
tion K:BACKBG. 


These four addresses must be in increasing order. That is, the core allocation must be made in the same order as the 
SYSGEN input. If nonresident foreground is used, it must be at least 218 cells long. This area is used as a buffer for 
the 'Q' key-in. 



SYSGEN OUTPUT 

MESSAGES TO THE OPERATOR 

The error messages in Table 28 can be output by SYSGEN. 
Note that for input errors (except for an allocation error), 
the corrected input must be made from the KP exclusively. 

BINARY OUTPUT 

If a background PM (Punch Monitor) operational label is 
assigned at SYSGEN time, SYSGEN will punch a reboot- 
able version of the RBM on the PM device after the last 
parameter has been input by the operator. 



The option to be input on OC should be either one of the 
following: 

PA specifies that patches are to read from the input 

device, with the format xxxxfefcyyyyLfefczzzz] . . . 
!EOD where xxxx is the location to be patched, 
and yyyy and zzzz are the values to be inserted 
at location xxxx. All entries must be four char- 
acters long, separated by two blanks. The !EOD 
terminates patching and causes the !!INPUT 
OPTION message to be output again. The ALL 
or UPD option can then be entered. 

ALL which specifies that a complete system load 
is to occur and nothing on the RAD is to be saved; 



SYSLOAD 

SYSTEM LOAD 

After SYSGEN has been completed, or the rebootable RBM 
deck punched by SYSGEN has been input, control is trans- 
ferred to the System Load Processor, SYSLOAD. SYSLOAD 
will initailly output the following message on the OC 
device: 

!!RBM SYSLOAD 

!! INPUT OPTION 



UPD which specifies that an updated version of RBM 
has been made to replace the existing RAD version. 
Portions of the RAD may have to be reloaded, de- 
pending on the new core memory allocation. 

ALL OPTION 

An ALL input specifies that a complete system load is to 
occur. A complete load is necessary for the initial genera- 
tion or whenever any of the RAD areas has to change size. 

The System Load Processor (SLP) first searches the Master 
Dictionary left by SYSGEN to determine if any RAD areas 
have not been completely defined because of an ALL input 
during SYSGEN. If some areas still need their last word 
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Table 28. SYSGEN Error Messages 



Message 


Meaning 


Recovery 


!! INVALID PARAMETER 


Input parameter is out of 
expected range, or maximum 
number of allowable Inputs 
have been made. 


Retype input with correct value. 


!! FORMAT ERR 


Input format not valid. 


Retype input with valid format. 


!!C. T. INT. PRIORITY ERR 


Control task interrupt is at 
a higher priority level than 
the I/O interrupt level. 


Requires hardware modification, or reassignment 
of Control Task Interrupt to a lower level. 


I ! I/O ERR 


An I/O error has occurred 
on the last input. 


Correct the problem with the input device and 
retype last input. 


!! ALLOCATION ERR 


No RAD was defined as the 
system RAD. 


Since this alarm is output only after the END card 
is input (i.e., after the RAD allocation has been 
completed), the user must reallocate all areas 
assigned to the system RAD. The default allocations 
will be restored for the second iteration. The com- 
puter will enter a "wait" state so that the error can 
be isolated and corrected unlike other SYSGEN 
errors. The corrected Inputs must be made on the 
original input device. 


TOO MANY AREAS 


Not enough entries were 
defined in the Master 
Dictionary. 


Fewer entries must be input or more Master Dic- 
tionary entries must be made available. In any 
event, RAD allocation must be restored. 


RBM CAN'T BOOT 


RBM resides on a 7242 disk 
and crosses a cylinder 
boundary. 


SP must be reallocated during a second RAD 
allocation. 


!! ILLEGAL OP. LBL. 


The user has attempted to 
permanently assign one of 
the reserved op labels (RM, 
ML, PI, OV, GO). 


Retype Input with different op label. 



addresses defined, S LP will generate this value so that the 
Master Dictionary can now be completed. 

At this point a check Is made to determine If the check- 
point area is large enough to contain the entire background. 
If It Is not, the following message will be output: 

CP AREA TOO SMALL 

I The CP area will be undefined. 

This error Is only fatal If an attempt is made to checkpoint 
the background. It can be corrected only by a complete 
SYSGEN, using at least the default size for the check- 
point area. 

I 

After the Master Dictionary has been completed, the SLP 

will write zeros on all defined areas of the RAD. This pro- 
cess takes approximately 1 minute for a 256-track RAD. 



LOADING RBM PART 2 

At this point the SLP outputs the following message: 
1 ! LOAD RBM PART 2 

If SLP encounters a track upon which it cannot write, an 
appropriate message will be output and that track number 
will be entered in the Alternate Track Pool. For a disk 
device, SLP will clear only the first sector of each area, 
and will obtain bad track numbers for the Alternate Track 
Pool from the headers of tracks 4000 to 4360. 

SLP will then write the following Into the first sector of 
each area: the area mnemonic, the bounds of the area, 
and a bad track list for all bad tracks on that device. SLP 
will also clear the second sector of each area. 
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The binary modules making up Part 2 should be input from 
the background AI device (as determined at SYSGEN). 

So that a user does not have to reorganize Part 2 for each 
new SYSGEN, SYSLOAD allows all or Part 2 to be input 
each time, but only loads the routines specified by the 
options selected during SYSGEN. The final module must 
be followed by an !EOD, The i dent from the Extended 
Symbol directive, IDENT, is used to identify each module 
loaded, and is placed in the OV:LOAD table and used as 
the overlay identification. 

RBM PART 2 

The routines making up RBM Part 2 and their idents are 
listed in Table 29. 

Table 29. Routines and Idents for RBM Part 2 







Ident 




Group 


Overlay 


(hexadec 


mal) 


Monitor 


M:ASSIGN 


Al 




Service 


M:DEFINE 


A2 




Routines 


M:OPEN 


A3 






MrCLOSE 


A4 






M:LOAD 


A5 






^ M:DOW 


A6 






MrWAIT 


A7 






MiCTRL 


A8 






M:RSVP 


A9 






M:DATIME 


AA 






M:COC 


AB 






RAD Bootstrap 


AC 




Control Task 


S:CKPT 


1 




Subtasks 


S:REST 


2 






S:LOAD 


3 






SrABORT 


4 






S:TERM 


5 






S:KEY 


7 






S:KEY2 


71 






S:KEY3 


72 






S:KEY4 


73 






S:PMD 


8 






S:CCI 


B 






SrPARPWR 


FF 






Power Failure 


Bl 




Background 


BACKCCI 


10 


Debug 


All Overlays 


20-2F 


Device- 


All 


30-3F 




Dependent 








Error Recovery 








Routines 








Miscellaneous 


Core Dump and 






Routines 


RAD Dump 


40 






Hex Corrector 


41 






FCT Dump 


42 





SYSLOAD loads the required overlays, absolutizes them for 
their execution location, and writes each overlay on the 
RAD in an unpacked format. Only one overlay can occupy 
the overlay area in memory at any one time. SYSLOAD 
stores the RAD address (as a displacement) and the word 
count of each overlay in the RBM OV:LOAD table. The 
OV:LOAD table has the following format: 



OV:LOAD 



Number of entries 



FWA 



Ident 



Word size 



First 
entry 



15 



Consecutive entries 



where FWA is the starting sector number (relative to the be- 
ginning of the system processor area) of this overlay. All 
overlays start on a sector boundary. No overlays cross a 
track boundary. 

If an error condition occurs during the loading of the indi- 
vidual modules making up RBM Part 2, the following mes- 
sage is output: 

XX ERR, IDrYY 

??RETRY? 



where 



XX is one of the following error types: 

XX Error Type 

CS Checksum. 

SQ Sequence. 

TY Item type; no external references or 

definitions are allowed. 

BI Binary deck is incomplete. 

OG Origin error; an attempt has been 
made to re-origin a portion of this 
routine to a region already on the 
RAD. 

YY is the ident of the current routine (if the ident 
is unknown, YY = ??). 



The response to the RETRY query can be either N (no) or 
Y (yes). If the response is N, the SLP skips to the next 
routine. If Y is input, the current routine is left as is and 
an attempt is made to continue with the next card; for some 
of the above errors, however, continuing in this manner may 
be undesirable. 
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After loading all of RBM Part 1, SYSLOAD determines if all 
required routines are present. If some routines are missing, 
the following alarm is typed: 

I! MISSING IDENTS: xx xx xx xx . . . 

?? RE LOAD? 

where xx is the ident (Extended Symbol directive IDNT) 
corresponding to the missing routine. 

If Y is input to the reload query, SYSLOAD again reads the 
AI device to load the missing routines. This sequence is 
repeated until all required routines are loaded or until an N 
is input. 

After RBM Part 2 has been loaded, entries will then be 
made in the System Processor Dictionary for RBM, the Trans- 
fer Vector Table, and the RBM bootstrap. Each of these 
Items is assigned in a separate file in the system processor 
area of the RAD. 

After the nonresident portion of the RBM is on the RAD, the 
resident portion is written. SYSLOAD calculates the lOCDs 
needed to read RBM into core storage and stores the infor- 
mation into the last part of the RAD bootstrap. 

After RBM is written on the RAD, the Transfer Vector Table 
will be written onto the TVECT file. The Transfer Vector 
Table contains transfer vectors for Monitor service routines 
and Public Library routines. The amount of RAD space allo- 
cated for the TVECT file depends on the maximum number of 
DEFs in the Public Library, which is a SYSGEN input. 

The final program output to the System Processor area of the 
RAD will be a copy of the RBM bootstrap that goes into the 
BOOT file. There is no file header for the bootstrap, and 
the bootstrap is always restricted to one sector. It is neces- 
sary to define the bootstrap as a file, so that it can be ac- 
cessed for output during a RAD save or dump operation. 
After the bootstrap is written onto the BOOT file, it is writ- 
ten onto relative sector zero of the system RAD, from where 
it can be bootstrapped into core. Also, a copy of the RAD 
bootstrap may be output to the foreground BOdevice, which 
enables the user to start RBM on any sector of the RAD or to 
boot from a disk pack. If the user chooses to start RBM at 
any sector other than sector zero, he can still reboot RBM by 
loading the RAD bootstrap that was punched on the BO device. 

The next output to the RAD will be the RBM Symbol Table 
(a file in the System Data area) and the System Data Area 
Dictionary. The System Data Area Dictionary has the same 
format as the System Processor Dictionary and contains the 
following files: 

File Name Description 

RBMGO Object module storage for "assemble and 

go" operations. 

RBMOV Nonpermanent storage for programs to be 

executed. 



File Name Description 

RBMS2 Storage for Extended Symbol standard 

procedures. 

RBMSYM RBM Symbol Table of Monitor service 

routines. 

RBMPMD RAD area used by postmortem dump. 

RBMID Holds IDNT origins for Debug. 

RBMAL Used by the accounting routine. 

If a user accepts the default allocation for the RBMGO, 

RBMOV, RBMAL, RBMID, RBMS2, and RBMPMD files, no 

modifications via the RAD Editor have to be made for 
these files. 

The RBM Symbol Table contains the definitions (DEFs) for the 
Monitor service routines. These DEFs are needed by the 
Overlay Loader at load time to satisfy any reference to the 
Monitor service routines. The first word of the table con- 
tains the number of bytes in the table, followed by seven 
words per entry, in the same format as in the Overlay 
Loader Symbol Table. 

After the System Load Processor completes its writing of the 
system data area, it moves the RAD bootstrap to memory 
locations through 63 and transfers control to the bootstrap. 
Then the bootstrap goes through its normal loading proce- 
dure (described later in this chapter in "Initial Loading of 
System Processors"). 



UPD OPTION (UPDATE) 

The UPD option on the SYSLOAD command specifies that a 
new version of RBM has been made, but that none of the 
areas on the RAD have changed in size. The option can 
also be used when changes are made in any of the following 
input parameters: 

• Public Library (PL) FWA 

• Resident Foreground FWA 

• Nonresident Foreground FWA 

• Background FWA 

UPD should not be used if any of the RAD areas has changed 
in size or location. In this case, a complete SYSGEN and 
SYSLOAD must be performed. Note that a change in the 
background FWA to increase the total size of background 
might cause a change in size of the Checkpoint area, which 
could necessitate a complete new SYSGEN. In this case, a 
CP AREA TOO SMALL alarm would be output for the user's 
information. 

The System Load Processor reads the bootstrap to determine 
where the old version of the RBM is located on the RAD and 
then loads the Monitor Constant Table. The SLP then com- 
pares the old load addresses against the new load addresses 
to determine which programs on the RAD must be reloaded. 
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The size of the new Master Dictionary must be at least as 
large as the old Master Dictionary. If it is not, an error 
message will be output and SLP will continue 

If the new version of RBM exceeds the RAD space allocated 
to the old version, all programs in the System Processor area 
and all programs that make external references to Monitor 
service routines (MSR) must be reloaded. (Reloading the 
System Processor area is necessary because the RBM is the 
first file In the area. ) As the comparison checks are made, 
a subset of the following messages will be typed on OC: 

!! RELOAD 

PUB. LIB. 

RES. FGD. 

NONRES. FGD. 

BCKG. 

SP AREA 

MSR/PL USERS AND PL 

NOTHING 

If any of the following modules are relocated on the RAD, 
the contents of other affected areas must be reloaded: 

Relocated Module 



Required Reloading 



Public Library requires All programs that reference the 
reloading because its Public Library must also be re- 
load address has loaded. None of the system 
changed. processors use the Public Library, 
and no system processors would 
have to be reloaded. 

Resident or nonresident The appropriate routines must be 
foreground was reloaded in these areas, 

relocated. 



Background was 
relocated. 



New RBM version ex- 
ceeds its allocated 
RAD file space. 



TVECT Table load 
address has changed. 



All system processor and back- 
ground user programs must be 
reloaded. (See "Initial Loading 
of System Processors" below.) 

All programs in the system pro- 
cessor area must be reloaded. 
(See "Initial Loading of System 
Processors" below. )* 

All programs referencing Monitor 
service routines (MSR) or the 
Public Library (PL) through the 
TVECT Table via an external 
reference must be relocated. 



The only areas of the RAD that would never have to be re- 
loaded are the system and user library areas since these 
areas contain library programs in relocatable binary format. 

The TVECT load address will change any time the first 
word address of the area adjacent to RBM in core has 
changed. 



After these checks are made. The SLP outputs the message 

I! LOAD RBM PART 2 

and proceeds to load the overlays as described earlier in 
the "ALL Option". 

After the overlays are loaded, another check is made to see 
if the overlays did not overflow RBM. If the overlays did 
overflow into the next area, the following message is output: 

II RELOAD 
SP AREA 

After the necessary RELOAD alarms are output for the user's 
information, the SLP will load the Master Dictionary from 
the RAD version of RBM and store it into its allocated area 
in the new version of RBM. The new version of RBM will 
then be written onto the RBM file, followed by an updated 
bootstrap in the BOOT file, the starting sector of the system 
RAD, and the PM device. Finally, the Transfer Vector 
Table and the RBM Symtol Table will be updated and then 
rewritten on the RAD. 



INITIAL LOADING OF SYSTEM PROCESSORS 

For a complete system load, the first processor that is loaded 
must be the Overlay Loader. The Overlay Loader is coded 
in a self-relativizing format and is loaded by the RBM Abso- 
lute Loader. An entry in the System Processor Dictionary 
for the Overlay Loader will be made at SYSLOAD time. 

The object module of the Overlay Loader will be loaded 
from the Aldevice and written Into its assigned file. The user 
must precede the loading of the Overlay Loader with an SY 
key-in and an lASSIGN OV=OLOAD,SP control command. 

After the Overlay Loader has been loaded onto its perman- 
ent file, it is available to load a relocatable binary deck of 
the RAD Editor onto the RBMOV file of the RAD. The RAD 
Editor is then executed via an IXEQ command and makes an 
entry for itself in the System Processor area by means of an 
!#ADD control command. It then should be copied onto its 
defined file. At this point, the System Processor area of 
the RAD contains the Overlay Loader and the RAD Editor, 
which are the only processors needed to complete the load- 
ing of other programs. 



PUBLIC LIBRARY CREATION OR UPDATING 

The Public Library can be created after the Overlay Loader 
and RAD Editor have been loaded and thereafter can be com- 
pletely regenerated any time the user desires. A file with 
the name PUBLIB will have to be defined via the RAD Editor 
in the User Processor area for the Public Library, and a file 
named LIBSYM must be defined in the System Data area of 
the RAD. The relocatable binary decks of all routines to be 
specified as being in the Public Library are loaded by the 
Overlay Loader (via the !$PUBLIB control command) and an 
absolute core image version is written by the Overlay Loader 
on the RAD file defined as PUBLIB. Before executing the 
Overlay Loader, the operator must key in SY so that the 
Loader can write in a protected RAD file. 
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When a Public Library is successfully loaded, additional up- 
dating of RAD files will be done by the Overlay Loader. 
The Public Library Transfer Vector Table will be input from 
the RAD and either created (for an initial load) or updated 
for succeeding loads. This process consists of linking each 
Public Library definition (DEF) in the Symbol Table to a 
transfer vector, and linking the transfer vector to the value 
of the DEF. When the linkage is completed, the Overlay 
Loader writes the new Public Library Symbol Table into a 
previously defined file (called LIBSYM) in the system data 
area of RAD. For an initial load, this file will be previ- 
ously defined, via the RAD Editor, with the name LIBSYM. 
The new Transfer Vector Table is then written on the RAD (re- 
placing the previous one), and the Loader exits toM:TERM. 
(Note that RBM must be rebooted from the RAD in order to 
load the Public Library into core memory.) The Public 
Library should not be loaded into core (by rebooting the 
system from the RAD) until the user has reloaded all fore- 
ground and background routines that use the Library. 



RESIDENT FOREGROUND CREATION OR UPDATING 

In an initial load the resident foreground files must be de- 
fined via the RAD Editor. These files must be in the User 
Processor area (UP) of the RAD. Also, the parameter on 
the !*ADD command specifying that this is a resident fore- 
ground file will have to be set. One RAD file can be de- 
fined for each foreground program, thus allowing an update 
to be done on a program basis as opposed to the entire resi- 
dent foreground area. On an initial load the Overlay 
Loader reads in a relocatable binary deck of each fore- 
ground program, and creates an absolute core image version 
of the program in its predefined RAD file. Foreground pro- 
grams assembled as absolute sections must be loaded with an 
ABS control command. Prior to executing the Overlay 
Loader, the user may key in SY to specify that the protected 
RAD files can be written on. 

For an update, only those programs being modified need be 
reloaded. However, if a program exceeds its allocated core 
space, other programs must be reloaded and relocated at a 
new absolute address in a different area of core. 

The Overlay Loader (or the Absolute Loader) will store in 
the first sector of each file the appropriate header informa- 
tion that the RBM bootstrap needs to load and initialize each 
foreground program. The information needed by the boot- 
strap consists of the following items: 

1 . Load address. 

2. Number of bytes in program, 

3. Entry address of initialization routine (if present). 

If no initialization routine is specified, the RBM bootstrap 
will initialize the task's interrupt level from information in 
the TCB. The task may also be triggered at this point if the 
TCB so specifies. 

After the resident foreground is loaded on the RAD, it 
is brought into core by manually rebooting the system 
from the RAD. It can also be brought into memory by 
inputting a Iprocessor or !XEQ command with OV assigned 
to its RAD file. 



When core is reloaded from the RAD, all newly loaded 
Public Library and/or resident foreground programs will be 
loaded and executed, if appropriate (see the description of 
the RAD bootstrap process at the end of this chapter). 

When it is desired to test a new version of a resident fore- 
ground program in core before it becomes permanent on the 
RAD, it can be loaded and executed from the RBMOV file. 
After the program has been tested, it can be loaded perma- 
nently on the RAD using the previously described procedure. 



NONRESIDENT FOREGROUND CREATION OR UPDATING 

Nonresident foreground programs can be created or updated 
in their predefined RAD files at any time. The Overlay 
Loader will read In relocatable binary decks of the nonresi- 
dent foreground programs, convert their addresses to absolute 
form, and write them into their defined files. The nonresi- 
dent foreground files will be located in the user processor 
area of the RAD, and the definition of the files will be 
accomplished by the commands to the RAD Editor. 



SYSTEM PROCESSOR AND LIBRARY CREATION 

The system processors (Extended Symbol, Rod Editor, Basic 
FORTRAN IV, Concordance, and Utilities) can be loaded 
or updated by the Overlay Loader from relocatable binary 
decks. These processors will have their address converted 
to the absolute locations appropriate for the background 
area and will be written onto their predefined files in the 
system processor area. Any processor can then be executed 
by input of the appropriate Ixxx command (where xxx is the 
file name of the processor). 

The System Library will be input in relocatable binary form 
by the RAD Editor and written in relocatable binary form 
onto the system library area of the RAD. The construction 
of several dictionaries in the system library is performed by 
the RAD Editor. 



SYSLOAD ALARMS 

In addition to the RELOAD alarms listed previously and 
those concerned with loading RBM Part 2, the alarms given 
in Table 30 can be generated and are unique to SYSLOAD. 



REBOOTING THE SYSTEM FROM RAD 

The system can be rebooted from the RAD by manually 
causing sector zero of the system RAD to be loaded, or by 
reading in the RAD bootstrap previously punched on the 
BO device. The RAD bootstrap will initially move itself 
to high core and then read in RBM from the system pro- 
cessor area of the RAD. The information necessary to read 
in RBM is contained in the last cells of the bootstrap and 
is supplied by SYSLOAD when the bootstrap is written on 
the RAD or punched out. After the resident portion of RBM 
is loaded, control is transferred to another bootstrap that 
loads the remainder of the RAD. This bootstrap functions in 
the overlay region of the RBM. 
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Table 30. SYS LOAD Alarms 



Message 


Meaning 


Recovery 


CP AREA TOO SAMLL 


The size of background has changed 
and/or RAD area al located for a 
checkpoint is too small. 


To perform checkpoint, SYS LOAD will have 
to be rerun using the ALL option. 


INVALID PARAMETER 


An invalid input has been made to the 
INPUT OPTION request. 


Retype either ALL or UPD. 


UNPROTECT RAD 


One of the write-protect switches has 
been set on the RAD for an area that 
SYS LOAD is attempting to modify. 


Remove the write protection for the appro- 
priate area. 


EOT ON SP AREA 


An end-of-tape status has been re- 
turned while writing on the SP area. 
Not enough room has been allocated 
for the SP area. 


A new SYSGEN will have to be run with an 
increase in the SP area. 


EOT ON SD AREA 


Same as for SP, except the SD area has 
overflowed. 


Same as for SP. 


RDdn FAULT 


A nonexistent address has been given 
for a seek operation. 


Check RAD allocation parameters in 
SYSGEN for allocation of more tracks than 
exist on this RAD. Repeat SYSGEN and/or 
SYS LOAD as necessary. 


MASTER DICTIONARY 
OVFLOW 


Version of RBM on RAD has a larger 
Master Dictionary than new version. 


Last areas of old dictionary were lost. A new 
SYSGEN may be necessary. 


ALT. TRK. POOL OVFLOW 


Too many bad tracks were encountered 
during the SYS LOAD process. 


Some bad tracks will not be in the Alternate 
Track Pool. A new SYSGEN may be 
necessary. 



The second bootstrap initially inputs the Transfer Vector 
Table to complete the loading of the resident portion of 
RBM. Next, an attempt is made to assign an operational 
label to the PUBLIB file in the user processor area. If a 
Public Library is present, the assignment will be made, 
and the bootstrap then inputs the Public Library. The 
bootstrap then searches the User Processor Dictionary for 
all files flagged as a resident foreground file. All such 
files are input, one file at a time, and an inialization 
routine is executed if one exists. The initialization routine 
can do any required housekeeping (such as repositioning all 
appropriate files), arm and enable the appropriate interrupts, 
and then return control to the bootstrap. The initialization 
routine is linked to via the following instruction: 

RCPYI P,L 

It then expects to have control returned to the address in the 
L register. Hence, the bootstrap will read in the resident 
foreground programs, one by one, and execute any initiali- 
zation routine. A provision is made to reboot the system 
without loading resident foreground. This is accomplished 
by setting all data keys to -1 just before clearing the 
"wait" state entered by the initial RAD bootstrap. 



The system is then completely rebooted and the bootstrap 
sets the protection registers, outputs the following messages, 
and enters a "wait" state. 

MAFTER 'WAIT' SET PROTECT 'ON' 

!! SET PARITY TO 'INT,' 

MINT. AND KEY IN 'S' TO BEGIN 



If the computer enters a "wait" state before the above 
messages are output, the bootstrap was not successful in 
loading the required data. This would usually be caused 
either by a parity error while reading the RAD or by a 
faulty foreground program. 

The above messages may be inhibited by setting DATA 
switch No. 2 prior to execution of the bootstrap. The 
indicated operations must still be performed, however. 

The loading of resident foreground can be inhibited by 
entering -1 in the data switches before executing the 
initial bootstrap. 
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12. DEBUG 



INTRODUCTION 

This chapter describes the use of Debug and its interface 
with RBM. 



GENERAL DESCRIPTION 

The RBM Debug package is a debugging tool primarily de- 
signed for nonoverlaid background programs, with limited 
facility for foreground programs. It provides the user with 
the following capabilities: 

1. To transfer control to the control device from a speci- 
fied location in the user's program or through the Con- 
trol Panel Interrupt. 

2. To dump selected core and registers on the keyboard/ 
printer or the line printer. 

3. To modify memory locations and registers, 

4. To logically insert code at specified memory locations. 

5. To begin or continue execution at a specified memory 
location (i.e. , selective execution). 

6. To perform conditional memory dumps (snapshots) of 
registers and selected core locations at a specified 
location and optionally transfer control to the con- 
trol device. 

7. To step through a program. 

FOREGROUND USER'S DEBUG CAPABILITY 

Debug can be used to aid the checkout of a foreground 
program operating at priority levels lower than the Con- 
trol Panel Interrupt level. In this case Debug must be 
assigned to an interrupt level higher than any level as- 
signed to the tasks being checked out. During real-time 
foreground program debugging, no background program 
may be executed and the background space can be used 
as an insertion area. The foreground user is able to force 
an unusual exit from the highest active interrupt level 
below Debug. 



OVERUY USER RESTRICTIONS 



When a snapshot is inserted in a currently resident seg- 
ment using a Debug control command, the snapshot is 
valid only until the segment is overlaid, since Debug 
operates only at execution time on resident programs. 
This problem is reduced by allowing the user to assem- 
ble Debug calls into his program. 



RBM AND FOREGROUND USER'S INTERFACE 

Debug is a subtask of the RBM Control Task with a priority 
just below the IDLE subtask. Debug is triggered by any of 
the three resident Monitor routines (D:SNAP, D:KEY, or 
D:CARD), by the KEYIN subtask, or by the Job Control 
Processor (JCP). JCP triggers Debug when it receives an 
XED command, and the system loader transfers control via 
D:KEY. When a foreground user wishes to use Debug, he 
gives control to Debug by an !XED card or by an unsoli- 
cited key-in of DE. After Debug has control, the fore- 
ground user defines an interrupt level for subsequent Debug 
use. At this time Debug saves the RBM group code 
(RrRBMWD) and the register bit (R:RBMB), replaces them 
with the computed user's group code and register bit, inhi- 
bits interrupts, triggers the new Debug level, and exits (re- 
setting inhibit bits) from RBM. The RBM Control Task is 
now operating at a level where Debug can affect the fore- 
ground user's program. After debugging, the foreground 
user issues the Debug command Q which restores the RBM 
Control Task to its original level. 

MEMORY REQUIREMENT AND INSERTION 
BLOCK DEFINITION 

The executive portion of Debug is a foreground program that 
may be resident or nonresident. If the program is resident, 
it must be so specified when the Debug file is created with 
the RAD Editor. It is read into core when RBM is booted. 
If the program is nonresident, it is loaded like any other 
foreground program (see Chapter 6). Debug has the fol- 
lowing core memory requirements: 



1. Executive 

2. Zero table 

3. Overlays 

4. Insertion block 



440 locations 
35 locations 
RBM overlay space 
User-defined 



The insertion block is an area of core that stores user- 
inserted code, and the zero table cells are used to refer- 
ence these insertions (see Appendix B). 

DEBUG CONTROL 

Control can be given to Debug in the following ways: 

1. A direct coll to Debug. 

2. The execution of a snapshot. 

3. An unsolicited key-in of DE. 

4. The Debug execution card (!XED). 

A direct call on Debug is a user-coded request for Debug to 
read a command. The call has the form 



RCPYl 


P,A 






B 


D: KEY or D:CARD 










Debug 
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When the entry is D:KEY, Debug prints the message 
MDKEYIN 



A Debug command will then be read from the proper device - 
file number assigned at SYSGEN, 

Note thatafter the initial direct call on Debug a foreground 
task will have to exit in order to move Debug to a higher 
interrupt. 

D:KEY, D:CARD, DrSNAP (snapshot) are small reentrant 
routines thatactually trigger Debug. An unsolicited key-in 
during Debug will not harm the user's environment; and if 
dump was in progress, the key-in will be honored after 
the current line is output. The IXED command performs the 
same function as the !XEQ command except that Debug is 
called via D:KEY before executing the user's program. 



DEBUG COMMANDS 

After Debug has control, it interprets the following 
commands: 



Code 


Function 


D 


Define 


I 


Logically insert code 


S 


Insert snapshot 


X 


Step (move) snapshot 


R 


Remove snapshot or insertion 


T 


Perform selective dump on keyboard/ 



printer and Debug output device 

Perform selective dump on Debug output 
device 



c 


Set Debug input device to the card reader 


K 


Set Debug input device to the keyboard/ " 




printer 


M 


Modify memory 


B 


Branch (i.e., return control to program) 


E 


Exit from interrupt level 


Q 


Terminate Debug 



Most Debug commands specify registers and memory loca- 
tions. Registers ore specified as follows: 

RP Program address register 

RL Link address register 

RT Temporary register 

RB Base address register 

RX Index register 

RE Extended accumulator 

RA Accumulator 

RR All of the above 

Locations are specified in one of the following forms: 

1. One to four hexadecimal digits. 

2. SNAME, where NAME is an IDNT and its value is the 
load origin of such module. The Overlay Loader D 
option must be invoked if the user is to use IDNT names 
with Debug. 

3. Sums or differences of values of either of the above two 
forms. 

Examples: 

A14 
SSQRT 

ABC+$SUB1+1492 
SSUBl - $SUB2 

If the SNAME option is invoked, the user must define an in- 
sertion block (see the Debug Define command, below), and 
the last 180 words of the insertion block are used as a buffer 
for the IDNT names. 

D (Define) 

The Define command is used to define an insertion block 
when the Debug commands S or I or the SNAME option is to 
be used. 

The form of the Define command is 

/ 

D [start, end] [, level] 



Debug uses MrREAD and M:WRITE for input/output; and 
hence the keyboard character NEW LINE terminates a line, 
EOM deletes a line, and cent [f^) deletes the previous 
character. Debug interprets the semicolon character (;) 
(if not in the message field of a snapshot) as a continua- 
tion character. The semicolon will terminate the line (or 
card and continue the command to the next line (or cord). 
Blanks are ignored except within the message field of a 
snapshot. 



start is the memory location of the first cell of the 

insertion block. 

end is the memory location of the last cell of the 

insertion block. 

level specifies the memory location of the hardware 

interrupt level if Debug is to be used for foreground. 
The default level is the RBM Control Task level. 
An unsolicited key-in of FG must be in effect when 
the level is specified. 
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(Insert) 



The Insert command designates the Insertion of one or more 
instructions logically before (IB), after (lA), or replacing 
(IR) the instruction at the designated location (loc). 

The form of the Insert command is 



loc, inst,, . . . , inst 
' In 



IB designates Insert Before 

lA designates Insert After 

IR designates Insert Replace 

The instructions may be designated in one of the following 
forms: 

1. op* loc 

where op isa two-digit hexadecimal value representing 
the operation code and address modification. The sec- 
ond digit (i.e., address modification) must be one of 
the following: 

designating direct addressing 

2 designating indexing 

4 designating indirect addressing 

6 designating indirect addressing and indexing 

This instruction form relieves the user of creating the 
actual address structure for Sigma 2/3. It does not apply 
to the conditional branch instruction (operation code 
6) nor to the register copy Instructions (operation 
code 7). Debug will actually expand on instruction 
designated In this form into more than one Instruction; 
for example, 82*1492 will expand Into 



8E02 


LDA 


*$+2, 1 


4802 


B 


S+2 


1492 


DATA 


X'1492 



See Appendix J for a description of the expansions. 

2. 6x*loc 

where x designates the desired conditional branch; 
for example, 6E*1492 designates a BAN 1492 and will 
expand into 



6E02 


BAN 


$+2 


4803 


B 


$+3 


4C01 


B 


*$+l 


1492 


DATA 


X'1492 



3. hex value 

which is Inserted with no expansion. 

4. Any mnemonic copy instruction In the Sigma 2 and 
Sigma 3 Computer Reference Manuals. The comma 
between the register specifications must be omitted. 

The results of an insertion are defined in Appendix N, 

An example of the insert command is as follows: 

IBSSUB+IOOO, 80*$SUB+25, 75A1, 40*SSQRT+0,; 
RCPYIPL,ROR*LT,REOR XB 

S (Insert Snapshot) 

The Insert Snapshot command Inserts (in the same manner as 
the Instruction Insert Before) a snapshot at the designated 
location so that when control passes through loc, the fol- 
lowing transpires prior to executing the instruction that was 
at loc: 

1. The optional conditions are evaluated, and If false, 
the snapshot Is bypassed. 

2. If the conditions are true (or if none are specified), the 
following is output: 

SNAP AT loc 

message (if any) 

followed by the designated dumps. 

Such output Is always transmitted to the Debug output de- 
vice; and If any of the dumps designate the keyboard/ 
printer, then the SNAP and the message line also will be 
transmitted to the keyboard/printer. A user con make a 
maximum of 32 snapshot and Instruction insertions. (See Ap- 
pendix L for the calling sequence for a Snapshot command.) 

The form of the Insert Snapshot command is 



S 

SK 

SS 



loc [/conditions/] ['message'] [,dump requests] 



^here 



S Is a request to snapshot and resume execution. 

SK is a request to snapshot and transfer control to 

the keyboard/printer for Debug input. 

SS Is the same as SK, but may be stepped (see 

Debug command X. ) 



See Appendix J for a description of the expansions. 



conditions 

message 

dump requests . 



are as described below. 
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Conditions. The format of the conditions is 



If} ^2{fl ^3 ••• (fl ^n 



where r. is a relational expression of the form 



'loc 




< 


'loc 


constant 


. H 


> 

< = 
> = 


constant 


register 




<> 


register 



where constant is the same form as a loc preceded by a ^; 
for example, 

#1492 or #SSUB+57 

The meaning of the operations in hierarchical order are 
as follows: 



= 


equal 


< 


less than 


> 


greater than 


< = 


less than or equal to 


> = 


greater than or equal to 


<> 


not equal 


& 


logical and 


1 


logical or 



The comparison is arithmetic unless the operator is preceded 
by an asterisk (*), in which case the comparison is logical. 

Message. Message is a string of any EBCDIC characters ex- 
cept quote ('). 

Dump Requests. The format of the dump requests (if any) is 
.. [T]. 



[T] 



register 

loc 

loc . . . loc 



register 

loc 

loc . . . loc 



where T designates a particular dump to be output on both 
the keyboard/printer and the Debug output device. If T is 
absent, the dump will be output to the Debug output device 
only. Only one dot (. ) is necessary in specifying a block 
of memory locations. Extra dots are ignored. 

An example of the snapshot command is as follows: 

S$SUB+505/RA=# 0&1492< 1496/' TAB 1 FULL', 
STAB 1... STAB 1+256, RR 

X (Step Snapshot) 

If control is at the Debug input device as a result of a 
stepping snapshot (SS), the X command moves the snapshot 



to memory location n, keeping the same conditions, mes- 
sage, and dump requests. Control is then transferred to the 
branch location. 

The form of the Step Snapshot command is 

/x [n [, branch]] 



n is the memory location. 

branch is the branch location. 

If the snapshot was executed at location ALPHA, the de- 
fault cases are branch = ALPHA and n - ALPHA+1. 

R (Remove Snapshot or Insertion) 

The Remove command restores the displaced instruction to its 
original memory location. The command releases the zero table 
entry and, if the entry is the latest snap or insertion, re- 
leases its space in the insertion block. Note that the space 
in the insertion block is regained only if the Remove com- 
mand affected the latest entry in the insertion block. 

The form of the Remove command is 



(' 



R loc, , ioc2/ . . ., loc 1 



where loc is the memory location. 

T (Selective Dump on the Keyboard/Printer and the 

Debug Output Device) 

The T command outputs the contents of the requested loca- 
tions and registers in hexadecimal on both the keyboard/ 
printer and the Debug output device. Console interrupt 
will transfer control to the keyboard/printer after the cur- 
rent line is output. 

The form of the T command is 



r 



dumps 



where dumps (i, e. , dump requests) have the following forms 
(there can be several dump requests in any order separated 
by commas): 



loc $SUB+3 

loc ... loc $SUB... 3FFF 

register RA 

all registers RR 
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(Selective Dumps on the Debug Output Device) 



Examples of the M command are 



This command is identical to the T command except that the 
dumps go only to the Debug output device. 

The form of the P command is 

y^P dumps 

C (Debug Input Device) 

The C command gives control to the Debug input device. 

The form of the C command is 



K (Keyboard/Printer) 

The K command gives control to the keyboard/printer. 

The form of the K command is 



M (Modify Memory) 

The M command modifies memory locations or registers. 
The form of this command may be either of the following: 
M register,word 




1. MSSUB+1, 4, 1, $SUB+2, RADDIZE 

where the following cells are modified if SUB is lo- 
cated at 100. 





16" 


Loc 


Value 


0101 


0004 


0102 


0001 


0103 


0102 


0104 


7C68 


MRA, SSUB 





loc, word^, . . ..word 
U' n 



This sets the A register to 0100. Note that an MRP 
command will change the program address portion of 
the program status doubleword. 

3. MT 149 A, RCPYIPA 

This will produce the following output if the contents 
of location 149A was FFFF prior to the command 
149A: FFFF— 75F1. 

B (Branch) 

The Branch command allows the user to insert loc into the 
program address portion of the program status doubleword 
and to exit from Debug, If loc is not present, the user just 
exits from Debug. 

The form of the Branch command is 
B [loc] 



E (Exit From Interrupt Level) 

The E command allows the user to force an unusual exit from 
the highest active interrupt level below Debug. Debug will 
still have control after this command. 

The form of the E command is 



loc is the first memory location to modify. 

wordj is the hexadecimal value (or mnemonic reg- 

ister operation; see Item 4 under the Debug I 
command) to be stored In the designated register 
or at location loc+i. 



P if present, is a request to print the hexadecimal 

value of the effective location, its previous value, 
and its new value. 

T if present, is a request to type the hexadecimal 
value of the effective location, its previous value, 
and its new value. 



Q (Quit Debug) 

The Q command causes Debug to reset its internal flags and 
zero table cells, restore RBM's original interrupt level, 
trigger the Job Control Processor, and exit. If the X option 
is present. Debug will also disconnect (i.e. , unload) itself 
from the system. 

The form of the Q command is 
Q [X] 
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DEBUG ERROR MESSAGES 



Error messages are shown below: 



Message 



ERROR SYNTAX 



Meaning 



Syntax error 



ERROR COMMAND Command error 



ERROR FOREGRND 



Command attempts to affect 
foreground without a hard- 
ware interrupt level specified 
for Debug (see Debug D 
command) 



Message 

ERROR OVERFLOW 



ERROR IN/OUT 



Meaning 

Either insertion block or zero 
table overflow 

Input/output error 

When Debug encounters an error, it aborts a background job 
if there is no [ATTEND card. Otherwise it requests further 
commands from the keyboard/printer. At this time. Debug 
will not have modified the environment, allowing the user 
to attempt recovery, (It is assumed that the user will respec- 
ify any erroneous commands.) 

A KEYIN error message issued as the result of an unsolicited 
key-in of DE, or an abort code of DE issued as the result of 
a direct call on Debug, implies that Debug is not part of the 
system. This can be corrected by queuing in Debug (i.e., 
an unsolicited key-in of Q DEBUG). 
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APPENDIX A. SIGMA 2/3 STANDARD OBJECT LANGUAGE 



INTRODUCTION 

TheXDS Sigma 2/3 standard object language provides a means 
of expressing the output of a processor in a standard format. 
Ail programs and subprograms in this object format can be 
loaded by the XDS Sigma 2/3 Overlay Loader. The complete 
standard object language contains 15 load item types. 

An object module consists of the ordered set of binary rec- 
ords generated by an assembly or compilation for later load- 
ing. The Overlay Loader has the facility to load and 
link several object modules together to form an executa- 
ble program. 

The Sigma 2/3 RBM System Absolute Loader can load a single 
module (absolute subset) to form an executable program. 
The following load item types from the standard object lan- 
guage comprise the absolute subset: 

1 . Record Header 

2. Record Padding (type 0, subtype 0) 

3. Repeat Load (type 0, subtype 1) 

4. Unre located Load (type 1) 

5. Start Module (type 4) 

6. End Module (type 5) 

7. Load Origin (type 7) 

This subset is acceptable input to the resident RBM Absolute 
Loader and Overlay Loader. 

DESCRIPTION OF OBJECT MODULES 

GENERAL DESCRIPTION 

An object module consists of a set of binary object records, 
each containing an integral number of load items after a 
standard three-word record header (see Figure A-1). Each 
binary record in the module Is a 120-byte record. 











FF 


n 


First Record 


Seq. No. 1 


Checksum 


Load Items 


Nonactive 
Information 










F F 


n 


Second Record 


Seq. No. 1 


Checksum 


Load Items 


Nonactive 
Information 











1 


(M-l)th Record 

Mth Record (Last record of modu 


e) 




F F 


n 


Seq.No.M-2 


Checksum 


Load Items 


Nonactive 
Information 








9F 


n 


Seq. No. M-1 


Checksum 


Load Items 


Nonactive 
Information 







Figure A-1. Typical Object Module of M Records (cont.) 

Each load item consists of a header word followed by a 
variable number of data words. The first load item in an 
object module is a start-module item and the last item (other 
than record padding) is an end-module item. There are 15 
types of load items, described below. 



BINARY OBJECT RECORD FORMAT 

Each 120-byte binary record in an object module consists of 
these parts: Record Header, Load Items, and Nonactive In- 
formation in the following arrangement. The Record Header 
and Load Items are considered the "active" portion of the 
record. 



Record Header 



Load Item 1 



Load Item 2 



3 words 



► up to 51 words 



Load Item n 



Nonactive 
Information 



Figure A-1. Typical Object Module of M Records 



The "active" portion of the record is that information con- 
cerning type, sequence number, checksum and binary data 
usually processed by loaders. The "nonactive" portion may 
contain sequence or identification information, or it may be 
empty. It is not processed by the loaders. 
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FORMAT OF RECORD HEADER 

The firsi- byte of the record header may be either X'F' or 
X'9'. X'F' denotes that this is a standard record of the ob- 
ject module: X'9' denotes that this is the lost record of the 
object module. 

word 



Control word | 


For 9 


F 


n 


n 


n 


n 


n 


n 



3 4 



9 10 11 12 13 14 15 



word 1 



s 


c 


Record sequence no. 









1 



word 2 



15 



Checksum 







15 



nnnnnn in the first word Is the number of active words in the 
record, excluding the record header. "Active" denotes data 
to be processed by a loader. There may be some padding 
words or sequence information at the end of the record that 
is not included in the "active" count. The maximum value 
of n is 51. Note that although the physical record size is 
fixed at 120 bytes (80 columns of binary data) the number of 
active words may vary from 3 to 54. This effectively stan- 
dardizes the reading of binary object records but allows ver- 
satility in the generation of active data. The record sequence 
number starts at and takes on consecutive integer values 
for all the records in one file. The S bit is a sequence over- 
ride. If this is a 1, the loader ignores sequence checking 
for the record. The checksum is an arithmetic sum, with 
carry, of the n-3 active words after the record header. If 
the C bit is a 1, the checksum is ignored. 

LOAD ITEM FORMAT 

Each load item consists of a one-word header and an op- 
tional variable- length body of data. 



Load Item Header 



Load Item Data 



■■ Load Item 



FORMAT OF LOAD ITEM CONTROL (Header) WORD 

Every header word has the same general format: 

bits 0-3 Type. 

bits 4-7 Subtype or control. 

bits 8-15 Number of data words in the load item (ex- 
cluding Item header). 

This number plus 1 is equal to the size of the 
load item. All words of a load item must be 
contained in the same physical record. 



SUMMARY OF LOAD ITEM FORMATS 

RECORD PADDING (Type 0, Subtype 0) 
word 



Control word | 




















1 







3 4 



11 12 



15 



There is no body of data. Padding words are Ignored by the 
loader. The object language allows padding as a conve- 
nience for processors. 



REPEAT LOAD (Type 0, Subtype 1) 
word 



Control word | 











1 











' 



3 4 



11 12 



15 



word 1 



Repeat count 







15 



This item repeats the next load item a specified number of 
times. The load item (type 1, 2, or 3 only) immediately 
following the repeat load is repeated (i.e., loaded) in its 
entirety the number of times indicated by the data word. 



UNRELOCATED LOAD (Type 1) 
word 



Control word | 








1 











n 


n 


n 


n 


n 


n 



3 4 



7 8 



11 12 



15 



word 1 



First data word 



15 



word n 



Last data word 



15 



This item loads n words without relocation. 



RELOCATED LOAD-MODULE BASE (Type 2) 



word 



Control word | 








1 








n 


n 


n 


n 


n 


n 



3 4 



11 12 



15 
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word 1 



First data word 



15 



word n 



Last data word 







15 



This item loads n words with module relocation. The reloca- 
tion bias of the current object module is added to each data 
word in the item. 

RELOCATED LOAD-COMMON BASE (Type 3) 

word 



Control word j 





1 1 











n 


n 


n 


n 


n 


n 



3 4 



7 8 



n 12 



15 



word 1 



First data word 



15 



END MODULE (Type 5) 
word 



Control word | 





1 


1 


r 














1 1 



word 1 




word 2 




word 3 







3 4 



11 12 



Starting address 



Severity level 



Relocatable size (or zero) 



15 



15 



15 



15 



This item identifies the end of the object module. In the 
control word (word 0), the starting address is defined in 
bit? 



word n 



Last data word 



15 

This item loads n words with a common base relocation. 

START MODULE (Type 4) 

word 



Control word | 





1 











n+ 1 



3 4 



15 



word 1 



Common size allocation 




word 2 



15 



First character 



Second character 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 







7 



15 



This item identifies the start of the object module. The 
characters in words 2 through n + 1 are the program name 
(identification) for the module. 



r = 1 indicates absolute starting address, 
r =0 indicates relocatable starting address. 

The severity level in word 2 is defined as the highest level 
reached during processing. 

The loader uses the relocatable section size, if present, rather 
than its own location counter to determine the starting loca- 
tion for the next relocatable section. 

A starting address of absolute indicates there is no starting 
address for this module. 

LOAD ORIGIN (Type 7) 

word 



Control word 



1110 



1 



3 4 



7 8 



11 12 



15 



word 1 



Origin address 



15 



This Item sets the origin within the object module. In the 
control word (word 0), the origin is defined In bit 7 



r=0 indicates relocatable origin, 
r = 1 indicates absolute origin. 
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RELATIVE LOCATION POINTER (Type 8) 
word 



Control word 1 


1 


OOOOOrOOO 





1 



3 4 



7 8 



11 12 



15 



)rd 1 



Chain base address 







15 



This Item establishes the chain base for later chain resolu- 
tion. In the control word (word 0), the chain base address 
is defined in bit 7 



r = indicates a relocatable address, 
r = 1 indicates an absolute address. 



NAME DEFINITION (Type 9) 
word 



Control word 



1 10 10 



3 4 



n+ 1 



7 8 



15 



word 1 



First data word 




word 2 



15 



First character 



Second character 



7 8 



15 



word n + 1 



(2n-l)th character Last character (or blank) 



15 



This item identifies a name as a definition within the object 
module. 



All name definitions immediately follow the start-module 
item and must precede all other load items. For each name 
definition, an address definition should appear later In the 
object module. 



word 1 



First data word definition — address 




word 2 



15 



First character 



Second character 



7 8 



15 



word n + 1 



(2n-l)th character 



Last character or blanks 







15 



This item associates a location In the module with a defini- 
tion name (characters in words 2 through n + 1) for other 
modules to reference. In the control word (word 0), the 
definition address is defined in bit 7 

where 

r =0 indicates relocatable definition address, 
r = 1 indicates absolute definition address. 

EXTERNAL REFERENCE (Type A) 

word 



Control word j 


1 


1 r 


n+ 1 



3 4 



7 8 



15 



word 1 



Chain qddress (or zero) 




word 2 



15 



First character 



Second character 



15 



word n + 1 



(2n-l)th character 



Lost character (or blank) 







7 



15 



This Item states a name (characters in words 2 through n+ 1), 
defined In another module, whose definition address must be 
inserted in a chain of locations within the module. In the 
control word (word 0), the chain address is defined in bit 7 



ADDRESS DEFINITION (Type 9) 
word 



Control word 


1 


1 r 


n+ 1 



3 4 



7 8 



15 



r = indicates a relocatable chain address, 
r = 1 indicates an absolute chain address. 

Note ; If there is no chain address, the reference address is 
zero and is used for library searching purposes only. 
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SECONDARY REFERENCE (Type B) 
word 



Control word 1 


1 


1 


1 


r 


n + 1 



word 1 




3 4 7 8 


15~ 


First data word chain address 






word 2 



15 



First character 



Second character 



7 8 



15 



word n + 1 



(2n-l)th character 



Last character (or blank) 







7 8 



15 



This item states a name (characters in words 2 through n+ 1), 
defined in another module, whose address may be inserted 
in chain of locations within the module. This item is iden- 
tical to type A, above, except that it does not force loading 
of the routine from the library. In the control word, the 
chain address is defined in bit 7 



r = indicates a relocatable chain address, 
r = 1 indicates an absolute chain address. 

ADDRESS LITERAL CHAIN RESOLUTION (Type C, sub- 
types 0, 1, 2, and 3) 

word 



Control word 1 


1 


1 


q r 








1 j 



3 4 



7 8 



15 



word 1 



Resolution address 



15 



word 2 



Chain address 







15 



This item defines a location within the module (called the 
resolution address) whose address must be inserted in a chain 
of displacement fields within the module. In the control 
word, the chain address is defined in bit 6 



where 



q = indicates a relocatable chain address, 
q = 1 indicates an absolute chain address. 



The resolution address is defined in bit 7 



r =0 indicates a relocatable resolution address, 
r = 1 indicates an absolute resolution address. 

An address literal chain is a threaded list of forward refer- 
ences to a single location in a program. The definition 
value (called the resolution address) can be output as an 
address literal chain resolution (Type C, subtypes 0, 1, 2, 
and 3). The chain address points to the beginning of the 
threaded list which is terminated by an absolute zero value. 
The resolution address and the chain address may be absolute 
or relocatable. 

Note: Because the terminator of the chain is zero, no pro- 
gram may have an address literal chain whose last 
link is at absolute zero (i.e., the item would refer- 
ence zero and would thus appear to terminate the 
chain). 

Note that external reference (REF) (type A) and secondary 
reference (SREF) (type B) chains are structured in the same 
manner, but resolved by the loader using an external defi- 
nition value (type 9). 

DISPLACEMENT CHAIN RESOLUTION (Type C, subtypes 
6, 1, A, and B) 

word 



Control word 



110 



P P q 



10 



3 4 



7 8 9 



11 12 



15 



word 1 



Resolution address 



15 



word 2 



Chain address 







15 



This item defines a location (called the resolution address) 
within the module whose relative displacement must be in- 
serted in a chain of displacement fields within the module. 
In the control word, the displacement chain is defined in 
bits 4-5 



where 



pp = 01 indicates that an indirect bit is not set in each 
instruction in the displacement chain. 

pp = 10 indicates that an indirect bit is set in each 
instruction in the displacement chain. 

q = 1 always indicates absolute displacement of the 
last item in the chain (relative to the chain 
base declared in item type 8). 
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The resolution address is defined in bit 7 



/here 



r = indicates a relocatable resolution address, 
r = 1 indicates an absolute resolution address. 

When forward references occur during one-pass processing, 
and the possibility of resolving the reference by a definition 
or literal may occur within 255 locations, the 8-bit dis- 
placement field of the instruction may be used to form a 
displacement chain. The item types 8 (relative location 
pointer — establish chain-base) and C (displacement-chain 
resolution) must be used together to resolve the chain by 
substituting actual displacements determined at load time. 

In the creation of a displacement chain, the pointer in the 
type 8 item defines the relative location in the program to 
be established as the chain base. Each new type 8 item con 
define a new chain base. The values In the displacement 
field of the Instructions included in any given displacement 
chain refer to the absolute displacement of that instruction 
relative to the currently established chain base; e.g., if the 
chain base is established to be X'lOO' and an instruction is 
located at X'125', the displacement of that instruction for 
purposes of the displacement chain is X' 125'-X' 100' or X'25'. 
This point is emphasized since the loader will use this dis- 
placement only to determine the final displacement of the in- 
struction relative to the location of literal or target locations. 

When the displacement chain connects instructions that ref- 
erence a literal or a specific target location within range of 
the chain base (e.g., LDA=3 LDA=LAB, B XR), no indirect 
bit is set In each Instruction (pp = 01 in Header — Type C). 

When the chain connects references to an external symbol 
or forward reference whose value will be given in some lit- 
eral within range of the chain base, pp is set to 2 in the 
type C header, to set the indirect bit in each instruc- 
tion in the chain (e.g., LDA X, which will be resolved 



as LDA *$+n, where n is the displacement of ADRL X rel- 
ative to the instruction). 

The chain base address (in the type 8 item) may be declared 
as an absolute or relocatable value. The resolution address 
(first data-word of a Type C item) is the address of the target 
location or literal expressed as a location, and not as a dis- 
placement on the chain base. Note that although the reso- 
lution address is defined at this point, the value of the literal 
at that resolution may not be defined until later. In fact, it 
may be an element of an address- literal chain (type C) or 
external reference chain (type A). The address- literal or 
external chain resolution is independent of the displacement 
chain resolution. 

The chain address given in the second data word is the ab- 
solute displacement of the last item in the chain, relative 
to the chain base declared in type 8 (e.g., if the effective 
chain base were X' 1000' and the value of the chain address 
were X'20', the last item of the displacement chain would 
be located at X'1020'). 

A separate displacement chain will be created for each 
unique variable in a given displacement region. Thus, many 
displacement chains may be built using the some chain base. 
As a matter of fact, the chain base may not be changed until 
a displacement chain resolution item has been output for 
each displacement chain. An unresolved displacement chain 
is a serious error condition in the output, and is unaccept- 
able for execution. 

The format of the displacement chain is described in the 
example in Figure A-2. 

Example: Let a chain base be declared at 109(R). (Numbers 
given ore decimal.) It Is assumed that the ADRL for XLB 
will be ultimately loaded at 140(R). Note that the displace- 
ment field of each Instruction before resolution is a pointer 
to the location of the next item in the threaded list relative 
to the chain base. 



Relative 
Location 
Counter 


Symbolic 


Displacement 
From Chain 
Base 


Displacement 
Field of Instruc- 
tion Before 
Loading 


Displacement 
Field of Instruc- 
tion After 
Resolution 


no 

125 
134 
136 
140 




LDA XLB 
STA XLB 
CP XLB 
STA XLB 




1 
16 
25 
27 


00 (end of chain) 

01 

16 

25 


30(140-110) 
15 (140-125) 
06 (140-134) 
04(140-136) 




Item Type C, Displacement 
Chain Resolution 












Resolution Address 140(R) 












Chain Address 27(A) 








— 



Figure A-2. Displacement Chain Format 
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APPENDIX B. SYSTEM ZERO TABLE AND CONSTANTS 



Table B-1. Monitor Zero Table 



Address 


Name 


Purpose and Assignment 


Dec. 


Hex. 



1 
2 
3 
4 
5 
6 
7 
8 



1 
2 
3 
4 
5 
6 
7 
8 


K:AC 

K:AC1 

K:AC2 

K:AC3 

KrFFLG 

KrBASE 

K:TCB 

R:IOP 


Reserved for Monitor Use. 

Pointer to Current Floating Accumulator. 

Pointer to Current Floating Accumulator (1). 

Pointer to Current Floating Accumulator (2). 

Pointer to Current Floating Accumulator (3). 

Pointer to Current Floating Flags. 

Pointer to Current Task Reentrant Temp Stack. 

Pointer to Current Task TCB. 

Pointer to 8-word lOP Table. 


9 
63 


9 
3F 




Standard Constants for Foreground, Monitor, and Background 
Use (see Table B-2 for complete list). 


64 
99 


40 
63 




IOCS Pointers and Constants. 


100 
132 


64 
84 




Reserved for Monitor Use. 


133 
134 
135 


85 
86 
87 




Debug Transfer Vector D:KEY. 
Debug Transfer Vector DrCARD. 
Debug Transfer Vector D:SNAP. 


136 
167 


88 
A7 




Reserved for Debug Use. 


168 
194 


A8 
C2 




Real-Time Foreground User Storage (reserved for foreground 
communication between foreground and background or for 
address literals or constants). 
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Table B-1, 


Monitor Zero Table (cont.) 




Add 


ress 


Name 


Purpose and Assignment 


Dec. 


Hex. 


195 


C3 




Power OFF. 




196 


C4 




Power ON. 




197 


C5 




Integral lOP timeout. 




198 


C6 




Watchdog Timer timed out. 




199 


C7 




Monitor Service Routines Transfer Vectors (see Table 7 for 


list). 


231 


E7 








232 


E8 




Monitor Constants (see Table B-3). 




251 


FB 








252 


FC 




Counter Interrupt Locations (optional). 




255 


FF 













Table B-2. Standard Constants 










Add 


ress 


Value 


Address 


Value 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


9 


9 


32768 


8000 


20 




14 


16 


10 


10 


A 


16384 


4000 


21 




15 


8 


8 


11 


B 


8192 


2000 


22 




16 


4 


4 


12 


C 


4096 


1000 


23 




17 


2 


2 


13 


D 


2048 


800 


24 




18 


1 


1 


14 


E 


1024 


400 


25 




19 








15 


F 


512 


200 


26 




lA 


-1 


FFFF 


16 


10 


256 


100 


27 




IB 


-2 


FFFE 


17 


11 


128 


80 


28 




IC 


3 


3 


18 


12 


64 


40 


29 




ID 


-3 


FFFD 


19 


13 


32 


20 


30 




IE 


-4 


FFFC 
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Table B-2. Standard Constants (cont.) 



Address 


Val 


ue 


Addt 


■ess 


Value 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


Dec. 


Hex. 


31 


IF 


5 


5 


48 


30 


14 


E 


32 


20 


-5 


FFFB 


49 


31 


-14 


FFF2 


33 


21 


6 


6 


50 


32 


15 


F 


34 


22 


-6 


FFFA 


51 


33 


-15 


FFFl 


35 


23 


7 


7 


52 


34 


-16 


FFFO 


36 


24 


-7 


FFF9 


53 


35 


32767 


7FFF 


37 


25 


-8 


FFF8 


54 


36 


32512 


7F00 


38 


26 


9 


9 


55 


37 


33023 


80FF 


39 


27 


-9 


FFF7 


56 


38 


65280 


FFOO 


40 


28 


10 


A 


57 


39 


255 


OOFF 


41 


29 


-10 


FFF6 


58 


3A 


61440 


FOOO 


42 


2A 


11 


B 


59 


3B 


3840 


OFOO 


43 


2B 


-n 


FFF5 


60 


3C 


240 


OOFO 


44 


2C 


12 


C 


61 


3D 


49152 


COOO 


45 


2D 


-12 


FFF4 


62 


3E 


31 


IF 


46 


2E 


13 


D 


63 


3F 


127 


7F 


47 


2F 


-13 


FFF3 











Table B-3. Monitor Constants 



Address 


Name 


Purpose 


Dec. 


Hex. 


226 
227 
228 
229 
230 
231 
232 


E2 
E3 
E4 
E5 
E6 
E7 
E8 


K:IOCS 

KrMASTD 

KrPAGE 

K.-BACBUF 

K:BACKP 

KrVRSION 


Pointer to IOCS Tables. 

Reserved for Monitor use. 

Pointer to Master Dictionary. 

Number of Lines/Printer Page (SYSGEN Parameter). 

Background I/O Buffer Pool FWA. 

Protected Background FWA (Start of TCB). 

RBM Version. 
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Table B-3. Monitor Constants (cont.) 




Address 


Name 


Purpose 


Dec. 


Hex. 


233 




E9 


KrPLFWA 


Public Library FWA. 




234 




EA 


KrRFFWA 


Resident Foreground FWA. 




235 




EB 


KrNFFWA 


Nonresident Foreground FWA. 




236 




EC 


KrBACKBG 


Unprotected Background FWA. 




237 




ED 


KrUNAVBG 


Unavailable Memory FWA. 




238 




EE 


KrBLOCK 


Size of Blocking Buffer in Words (180 or 512). 




239 




EF 


KrFEF 


FORTRAN Background Error Severity (1). 




240 




FO 


KrTVECT 


Pointer to Transfer Vector Table. 




241 




Fl 


KrFWA 


Legal TVECT Entries to FGD-FWA. 




242 




F2 


KrLWA 


Legal TVECT Entries to FBD- LWA+1. 




243 




F3 


FrFWAl 


TVECT FWA for T Register Check. 




244 




F4 


KrLWAl 


TVECT LWA+1 for T Register Check. 




245 




F5 


KrOLOAD 


Pointer to RBM OVrLOAD Table. 




246 




F6 


KrMTMP 


Size of Nondynamic Storage, in Words (6). 




247 




F7 


KrCCBUF 


Address of Control Card Buffer. 




248 




F8 


KrNRFQ 


Pointer to Nonresident Foreground Queue Table. 




249 




F9 


KrNEXT 


Next Available Sector in BT Area. 




250 




FA 


KrPROTCT 


Pointer to Protection Register Table. 




251 




FB 


KrPMDTBL 


Pointer to Postmortem Dump Table. 




These names are as defined in the RBM Monitor and are r 
these names must be defined in the user program (e.g., K: 


lot system definitions. Any references to these locations 
IOCS EQU X'E2'). 


by 


Relationships for Monitor Constants: 






1. 


(K:PLFWA) = LWA+1 of RBM. 


4. (KrBACKP)= LWA+1 of Nonresident Foreground. 


2. 


(KrRFFWA) = LWA+1 of Public Library. 


5. (KrBACKBG) = (KrBACKP) + 39. 




3. 


(KrNFFWA) = LWA+1 of Resident Foreground 


6. (KrCCBUF) = (KrUNAVBG) - 62. 
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APPENDIX C. RBM SYSTEM ABORT CODES 



The abort codes given in Table C-1 are the standard abort 
codes output by the Monitor, Basic FORTRAN IV Compiler, 
Extended Symbol assembler. Utility Subsystem, and RAD 
Editor (see also supplementary control command diagnostics 
in Appendix D). 



OVERLAY LOADER ABORT CODES 

The abort codes given in Table C-2 will be output by Over- 
lay Loader which will then exit via a call to the RBM 
routine MrABORT. 



LOADER I/O ABORT MESSAGE 

The I/O abort message has the following format, followed 
by the message "ABORT lO location": 

opib device type and number diagnostic 



opib is the operational label of the device or file 

on which the error occurred. 

device type and number pertain to the operational 

label. 

diagnostic is an error diagnostic corresponding to 

an I/O completion code.*^ 



The following diagnostics may be used: 

UNRECOVERABLE I/O ERROR 

CALLING SEQUENCE ERROR 

INVALID OPERATIONAL LABEL 

OL =0, OR OPERAT MEANINGLESS 

ILLEGAL END OF FILE 

END OF TAPE 

INCORRECT RECORD LENGTH 

ILLEGAL BUFFERING 

WRITE PROTECTED 

BEGINNING OF TAPE 

ILLEGAL RAD SEQUENCE 

BLOCKING BUFFER UNAVAILABLE 

An example of the I/O abort message is given below: 
BI MTDO END OF TAPE 
ABORT lO 3F4C 



See Table 10, "I/O Completion Codes", in Chapter 4. 



BI is the opib. 

MTDO is the device type and number. 

END OF TAPE is the diagnostic. 
3F4C is the ABORT lO location. 



Table C-1. RBM Abort Codes 



Code 



Meaning 



AE 

AI 

BI 

BO 

CC 

CK 

CS 



Assignment error during loading; improper I/O assignment or invalid format. 

Irrecoverable I/O error on device assigned to operational label AI. 

Irrecoverable I/O error on BI device. 

Irrecoverable I/O error on BO device. 

Error In control cards or in sequence of }ob stack. 

Irrecoverable error while checkpointing. 

Checksum error from absolute or relocatable binary input. 
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Table C-1. RBM Abort Ccxles (cont.) 



Code 



Meaning 



DE 

ER 

ES 

FC 

FS 

GO 

IE 

lO 

LO 

OP 

OV 

PE 

PU 

PV 

RE 

RS 

SI 

SQ 

TL 

TS 

TY 

UT 

XE 

XS 



Debug not resident when requested. 

Operator-recognized error condition. 

FORTRAN library abort^ 

Illegal FORTRAN control card. 

FORTRAN abort^ 

Irrecoverable error on output to the GO file when using a !REL command. 

Error in input deck. (Usually, a negative ORG item has been input. ) 

Irrecoverable I/O error. 

Irrecoverable I/O error on LO device. 

Operator abort, from unsolicited key-in. 

Problem with device assigned to operational label OV. (Normally, OV is assigned to the RAD, 

Parity error in background (perhaps attempting to read from unavailable memory). 

Number of argument greater than temporary storage in M:PUSH . 

Protection violation. 

RAD Editor abort . 

Irrecoverable error during restart. 

Irrecoverable input error in SI device. 

Sequence error in absolute or relocatable binary deck. 

Background program time limit exceeded. 

Temp stack overflow. 

Invalid load type in ABS deck. 

Utility subsystem abort . 

Fatal error in loading. 

Extended Symbol abort . 



^After the abort code is output, the processor will exit via the RBM routine M:ABORT. 

Notes: 1. The processing of the job stack is discontinued following any abort. If an ! ATTEND control command 

was in effect, the Monitor will enter an "idle" state. This will allow the operator to correct the problem 
and restart the (ob. If not in "attend", the Job Control Processor will read commands until a UOB or 
!FIN command is encountered. All control commands encountered prior to the !JOB or !FIN command 
will be logged In with an indication (">" will precede the command) that they have been Ignored. 

2. If Integral lOP timeout occurs, RBM checks foreground mailbox X'C5' for a watchdog receiver. If a re- 
ceiver is specified, RBM branches to it; otherwise, RBM holts with the address of the interrupt In the 
accumulator. An Integral lOP timeout Indicates hardware difficulties. 
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Table C-2. Overlay Loader Abort Codes 



Code Meaning 



AT Error In accessing the RBMSYM file. 

A2 Error in accessing the LIBSYM file. 

A3 Error in accessing the EBCDIC library file. 

A4 Error in accessing the DEFREF library file. 

A5 Error in accessing the MODIR library file. 

A6 No blocking buffer is available for the RBMID file. 

A8 Error in accessing the TVECT file. 

A9 Error In closing the RBMID file. 

BB Cannot use RS' op label because It is already used by Overlay Loader. 

CM A COMMON displacement or size larger than that stipulated on the lOLOAD command or In a start Item 
was detected. (Background abort only.) 

CR A non-COMMON Item was relocated Into COMMON. This condition only occurs when an actual data 
Item Is to be stored Into COMMON. 

DS The same identifier was used to name two different segments. 

EF An illegal end-of-file was detected. 

IT An Illegal Item type was detected. 

LI The library files cannot be loaded because of Incorrect construction of the library. 

On An Overlay Loader function that prevents proceeding has occurred. The number of the overlay In which 
the malfunction occurred Is indicated by n. 

PL Overlay Loader was unable to write the Public Library, the LIBSYM, or the TVECT files onto the RAD. 

RS Overlay Loader unable to correctly read the RBMSYM file from the SD area. 

SA Not enough segments were allocated for the task. The segments parameter of the lOLOAD command 
should be larger. 

SD Next segment of the Overlay Loader cannot be loaded. 

SE Input ROM had an error severity level greater than zero. 

SO Format or parameter error was detected on a !$SEG command. 

SL The length of a segment was excessive, (see !$ROOTand !$SEG commands for maximum segment size). 

TO There was a table overflow. Decrease the size of the program or reduce the number of external symbols. 

UN The number (on the !$SEG card) of the segment to which this one is attached has not been defined. 



Appendix C 153 



APPENDIX D. CONTROL COMMAND DIAGNOSTICS 



The following error messages may appear on the background 
DO device as a result of an error condition detected by the 
JCP. These diagnostics supplement the abort or attend error 
codes printed by the JCP. 



Message 

.BK OPLB/DFN TEL FULL 

.FG OPLB/DFN TBL FULL 

• ILLCrCODE 

• ILLCrTCB 

• ILL RAD SEQUENCE 

.INV COMMAND 



Comments/ 
Associated Commands 

ASSIGN, DEFINE, default 
assignments for system 
processors 

ASSIGN 

C: (Connect) 

C: (Connect) 

WEOF, REWIND, UNLOAD, 
FBACK, FSKIP, RBACK, RSKIP 

Command not recognized as 
a Monitor service command, 
system processor, or user 
processor. 



Message 



INV OPLB OR DFN 



. INV OPTION 



NO 'FG' KEY-IN 



NO 'SY' KEY-IN 



Comments/ 
Associated Commands 

ASSIGN, DEFINE, WEOF, 
REWIND, UNLOAD, FBACK, 
FSKIP, RBACK, RSKIP 



An invalid option has been 
encountered on a Monitor 
service command 



ASSIGN, XEQ,C: 



WEOF, ABS, REL 



OP NOT MEANINGFUL WEOR, REWIND, UNLOAD, 

FBACK, FSKIP, RBACK, 
RSKIP 



RAD TEMP OVERFLOW DEFINE, default assignments 

for system processors 
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The following table should be used to determine the standard assignments for an installation's RBM operational labels and to determine which operational 
labels, if any, should be suppressed by being assigned to file 0. The RBM operational labels are defined under the {ASSIGN command in Chapter 2. 



cn 



RBM'^'v.^erational 
and ^"^v^bels 
Processors ^""^..,,,_^ 


Device 
Number 1 


CC 


SI 


UI 


AI 


BI 


BO 


UO 


LL 


DO 


RBM 


ReadAVrite 
unsolicited 
key-in 


Read 

Control 

Commands 






Read 

Absolute 

Binary 


Read Object 
modules with 
! REL command 






Write Control 

Command 

Images 




XSYMBOL 




[Read Control 
commands] 


Read Source 
Statements 








Write Reloc. 
Binary 




Used for CC 
Diagnostics 


Write XSYMBOL 
Error Messages*^ 


Concordance 






Read Source 
Statements 














Write Concordance 
Error Messages^^ 


Basic FORTRAN IV 






Read Source 
Statements 








Write Reloc. 
Binary 








Math Library 




















Write Library 
Error Messages 


Overlay Loader 




Read 

Control 

Commands 
















Write Map, Loader 
Error Messages and 
Control Command 
Images 


RAD Editor 




Read 

Control 

Commands 








Object Module 
input to System 
and User 
Libraries 


Output Copies of Ob- 
ject Modules from Sys- 
tem and User Libraries 






Write Error Mes- 
sages, Control 
Commands and 
operator key-ins 


Utility Executive 




Read 


Read 

Control 

Commands 














Write Utility Error 
Message and Con- 
trol Command 
Images''^ 


Utility Copy^ 






Read Control 
Commands 


Read 
Input 














Utility RECEDIT 






Read Control 
Commands and 
Modific Input 


Read 
Input 








Write 
Output 






Utility OMEDIT 






Read Control 
Commands 


Read 
Input 




Read Binary 
Modific. Input 




Write 
Output 






Utility DUMP 






Read Control 
Commands 


Read 
Input 














Utility SEQEDIT 






Read Update 
Data 


Read 
Input 








Write 
Output 






May use any op label for output. 
Suppressed if assigned to same device as LO. 



X 



cn 



00 



o 

r— 
r- 

09 

m 

r— 

00 



RBM ^"""vQperational 
and ^\^bels 
Processors ^^x^^ 


LO 


LI 


PM 


OC 


XI 


PI 


OV 


X2 


X3 


S2 


GO 


X4 


X5 


RBM 






Write Abso- 
lute Binary 
Monitor (SYS- 
GEN only) 


Write Proces- 
sor and Mon- 
itor Abort 
Messages 




Read RBM 
Overlays 


Write Pro- 
gram Loaded 
by lABS 
Command 








Write Ob- 
ject Mod- 
ule with 
IREL 
command 






XSYMBOL 


WRITE Listing 
Output and 
XSYMBOL 
Error Messages 






Operator 
Commu- 
nications 


Intermediate 
Output 


Read 

XSYMBOL 

Overlays 




Output 

Encoded 

Text 


Output 
Program 
Locals 


Output 
Standard 
Proce- 
dures 


Output 
Execution 
Object 
Language 






Concordance 


Write Listing 
Output and 
Concordance 
Error Messages 


























Basic FORTRAN IV 


Write Listing 
Output and 
FORTRAN 
Error Messages 








Intermediate 
Output 


Read 

FORTRAN 

Overlays 










Output 
Execution 
Object 
Language 






Math Library 


Write Library 
Error Messages 






Operator 
Commu- 
nications 




















Overlay Loader 




Read Reloc. 
Binary 
Library File 




Operator 
Commu- 
nications 


Contains Sym- 
bol Table for 
each segment 


Read 

OLOAD 

Overlays 


Write 
Core 
Images 








Read 

Reloc. 

Binary 






RAD Editor 


Write Maps 
and Dumps 
of Files 






Operator 
Commu- 
nications 


Replace Files 
and Maintain 
Libraries 


Read RAD 

Editor 

Overlays 




Replace 
Files and 
Maintain 
Libraries 


Maintain Li- 
braries and 
Update Di- 
rectories 






Maintain 
Libraries 




Utility Executive 


Write Utility 
Error Messages, 
Control Com- 
mand Images and 
other Output 






Operator 
Commu- 
nications 




Read 

Utility 

Overlays 














Prestore 
Commands 
From SI 


Utility Copy 
























Input 

for 

Verify 




Utility RECEDIT 


Write Modi- 
fication Log 


























Utility OMEDIT 


Write Module Log 
















Prestore BI 










Utility DUMP 


Write Dump 


























Utility SEQEDIT 


Write Listing 



























APPENDIX F. CHARACTER-ORIENTED COMMUNICATIONS |COC| EQUIPMENT HANDLER 



This appendix describes the interface of RBM with the Xerox 
character-oriented communications (COC) equipment. '^ The 
COC equipment provides communication between Sigma 2/3 
real-time programs and various terminal devices. The COC 
consists of a controller and from one to eight attached line 
interface units, with each unit containing from one to eight 
send-and-receive modules. The Sigma 2/3 RBM can accom- 
modate one COC, which gives the user up to 64 lines each 
with send-and-receive equipment. The terminal devices 
supported (one per line) can be Teletype Models 33, 35, 
or 37. Other terminals can be connected but they must use 
ANSCII control codes, and all editing must be done by the 
user program. 

The computer requirements for use with the COC equipment 
are as follows: 

1. RBM with at least 16K of core memory. 

2. One buffered Input/output channel dedicated to the 
COC controller. 

3. Two external interrupts dedicated to the COC 
controller. 

4. External interface feature. 



3. A real-time task connected to the output interrupt of 
the communications controller, which transmits out- 
put messages and editing characters at end-of-message 
(EOM). 

4. Conversion tables (ANSCII to EBCDIC, and vice 
versa). 

5. An Input buffer (overlays the initialization routine). 

RCOC must be assembled separately for each installation 
unless the default cases for the installation specific assem- 
bly parameters agree with the parameters desired. The 
assembly parameters are as follows: 

1. The device number of the COC (buffered input/output) 
(default = 7). 

2. The COC number (direct input/output) (default = 0). 

3. The input interrupt level (even number of the even-odd 
pair) (default = 110). The output interrupt level Is 
assumed to be the odd number. 

4. Number of lines used (n), where all line numbers to 
n-1 are assumed to be used (default = 1). 



DESCRIPTION OF COC PACKAGE 



COC OPERATION 



The COC software package allows messages to be communi- 
cated via the character-oriented equipment, and consists 
of two sections — M:COC and RCOC. 



M:COC M:COC is a Monitor service routine that Initi- 

ates all read, write, and control operations. It Is part of 
the RBM overlays and requires no modification by the user 
before use. (M:COC is described In detail In Chapter 4.) 



RCOC RCOC consists of the following tasks and tables 

that make up a resident foreground program: 

1. An initialization routine. 

2. A real-time task connected to the Input Interrupt of 
the communications controller, which edits and trans- 
lates input characters, echoes the characters if re- 
quired and forms Input messages. 



See Xerox Sigma Character-Orlented Communications 
Equipment Reference Manual, Publication 90 09 81, for a 
description of the equipment Involved, the possible con- 
figurations, and the various uses for the equipment. 



RCOC is a resident foreground program and must reside on 
either the SP or UP area of the RAD. It is read into core 
memory and operated whenever RBM Is rebooted. The 
RCOC initialization routine turns on all transmitters and 
receivers, arms and enables the Input and output Interrupts, 
Initiates Input from the COC controller Into a wraparound 
buffer, and exits. At this point, all lines are set to the 
"disconnected" status, ready to be connected and used by 
the real-time programs. Input Is Initiated and an input In- 
terrupt is generated for each character Input, but the data 
are ignored until the line is connected and a read request 
Is given. 

All line-control and read-or-wrlte operations are Initiated 
by calls to M:COC. A request to read merely causes the 
line status to be set to "read", which In turn causes the 
Input Interrupt routine to accept Input from that line and 
build the input message In the user's buffer. A request to 
write causes M:COC to turn on the transmitter and transmit 
the first character In the user's buffer. Thereafter, an output 
Interrupt Is generated once each "output word time" (I.e. , 
once each time the transmitter can transmit). The output 
Interrupt routine transmits characters from the user's buffer 
until the entire message Is sent and then turns off the 
transmitter. 

As each Input or output message is completed, the status of 
the line Is set to "message complete" and an EOM Receiver 
(if present) Is operated at the Input or output Interrupt level. 
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The receiver should trigger the requesting task and return 
to the location contained in the L register. 

AUTOMATIC DIALING 

If the Automatic Dialing Equipment (ADE) is included, 
real-time tasks can dial a terminal and connect it to a 
predetermined COC line. The ADE is a multiunit con- 
troller that controls up to 16 dial positions. It requires a 
dedicated buffered lOP channel. 



RESTRICTIONS 

The priority of the input/output interrupt pair must be 
higher than any program using its services via M:COC 
and should also be higher than other real-time programs 
with long execution times. If a program with a higher 
interrupt priority runs for a long period of time, the 
input buffer may become filled and data may become 
lost. The output data would be delayed but no data 
would be lost. 



The dialing operation can be accomplished via M:IOEX. 
A TDV should first be performed to ensure that the dial 
position is available. Then an SIO can be issued to acti- 
vate the ADE and address the dial position. Any order byte 
will be interpreted as a "write". The memory buffer con- 
tains the number of the data set being dialed (two bytes 
per word; each digit occupies the rightmost four bits of the 
byte in four-bit BCD). After the dialing procedure has been 
completed, the task should check the status of the COC 
line before attempting to send or write on it. 



All COC lines (i.e., assembly parameters) are assumed to 
be operational. The RCOC initialization routine will 
loop, attempting to turn the receiver on for a nonexistent 
COC line number. 



If automatic dialing is included, the user must include 
M:IOEX during SYSGEN and must input the dialing posi- 
tions as XX type devices. 
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APPENDIX G. SYSGEN AND ASSEMBLY TIME OPTIONS 



The optional RBM capabilities below are obtainable as a 
package in response to the SYSGEN query INC. MISC. 
At least 100 (decimal) additional resident core memory 
locations are required. 

HEXADECIMAL CORRECTOR CARDS 

Patches may be loaded at execution time for either the 
Monitor itself or any user program. All corrector cards 
have the form 

aaaa cccc, [cccc_. . . cccc ][*comments] 



aaaa is the first (or only absolute core memory 

location to be modified. 

ccccj are the desired (hexadecimal) contents of 

aaaa and the following n-1 locations. 

Patches are loaded from CC In one of two ways: 

1. Following a HEX control command. 

2. Following an unconditional H key-in. 

All corrector decks are terminated by an EOD control com- 
mand. To patch relocatable programs, a bias card may be 
used. Its form is 

+bbbb 



To patch program segments, Data Switch must be placed 
in the "1" state. This causes the RBM to type "BEGIN 
SEG xx" (where xx is the segment number; XX = for the 
root) and go into an idle state after each segment is loaded. 
Correctors can then be loaded to the segment following an 
hi key-in. An S key-in will cause RBM to resume operation. 
The ability to type the message "BEGIN SEG xx" is deter- 
mined when RBM is assembled and is not related to the In- 
clusion of the"MISC." routines. 



THREE-CHARACTER PROCESSOR SEARCH 

An assembly time option exists for the Job Control Processor 
(which does not increase resident RBM) to identify a 
processor from the first three characters Input. 



When the Control Command Interpreter encounters a pro- 
cessor request such as IXSYMBOL, a search Is first made 
of the system, then the user processor area, to locate the 
file whose name matches the requested processor exactly. 
Normally, If this search fails, the Monitor aborts the fob. 
However, if this assembler option has been selected, the 
request is then truncated to three characters (I.e. , !XSY) 
and the search of the system and user processor areas Is 
repeated. Thus, if Extended Symbol has been defined on 
the system processor area of RAD as the three-character 
name !XSY, either a request of IXSYMBOL or ISXY will 
locate the system processor. 



where bbbb is the bias and the following correctors are 
loaded relative to that location. Any value (on a cor- 
rector card following the bias card) preceded by a plus 
(i.e., +cccc|) will have the bias added to It. 



An optional assembly parameter In the RBM subtask SrLOAD. 
This parameter does not increase RBM. 
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APPENDIX H. MEMORY REQUIREMENTS 



CORE SPACE REQUIREMENTS FOR RBM 

The minimum RBM system (which would consist of keyboard/ 
printer, paper tape, and RAD I/O routines, and a minimum 
number of RAD device-files and operational labels) requires 
about 43OO1Q cells for the Real-Time Batch Monitor and all 
Its tables. This minimum core space requirement will in- 
crease as handlers are added for additional peripherals, 
as additional optional software routines are chosen (see 
Table H-1) during SYSGEN, and as additional device- 
files, operational labels, or Public Library DBFs are allo- 
cated during SYSGEN. The following table indicates the 
approximate core space requirements for the additional rou- 
tines. Unless otherwise indicated, these number are only 
approximate and have been rounded to the next higher 
multiple of 25. 



Table H-1- Core Requirements for Additional Software 





Approximate 


Handler or routine 


size (decimal) 


Multiply/Divide Simulation 


175 


Software 




Power Off/On 


196 


MrlOEX 


188 


Job Accounting 


216 


Line Printer Handler 


79 


Card Reader Handler 


2 (exact size) 


BCD Option for Card 


2 (exact size) 


Reader 




Magnetic Tape Handler 


208 


Card Punch Handler 


2 (exact size) 


BCD Option for Card 


2 (exact size) 


Punch 




Each additional RAD Device 


15 (exact size) 


File 




Each additional Operational 


2 (exact size) 


Label 




Each Public Library DEF 


2 (exact size) 



must allocate at least 3800 cells for background to accom- 
modate the RBM Job Control Processor which executes in the 
background space. 

CORE SPACE REQUIREMENTS FOR THE 
RBM PROCESSORS 

The minimum background space necessary to individually 
load with the Overlay Loader program and to execute all 
the RBM Processors is 7K cells (IK = 1024io). The largest 
processor here is Basic FORTRAN IV, which requires 7K 
cells when it is loaded by the Overlay Loader. FORTRAN 
programs of reasonable size can be compiled in 7K of back- 
ground. Extended Symbol can be loaded in a minimum of 
6.25K of background, and a program of approximately 1200 
to 1800 instructions could be assembled in this minimum 
space. The other RBM processors can all be loaded and 
executed in less than 6K of background. 



RAD SPACE REQUIREMENTS 

Table H-2 gives the allocations for the system areas of the 
RAD, if a user chooses not to override the default case. The 
following discussion assumes a 360-byte-per-sector RAD. 



Table H-2. RAD System Area Requirements 



Area 


Size 


Comments 


Checkpoint 


n sectors 


n=size of background 
(in sectors). 


System 
Processor 


30 tracks 


Sufficient to contain all 
RBM processors plus RBM. 


System 
Library 


9 tracks 


Sufficient to contain two 
versions (extended and 
basic) of Math/Run-Time 
Library. 


System 
Data 


14 tracks 


RBM files. 



Hence, the resident core space requirements for RBM vary 
from 4300 to 6200 cells, depending upon the user's con- 
figuration. If background processing is desired, the user 



Note that this leaves approximately one spare track in the 
system data area. However, if a Public Library is included, 
the file LIBSYM must be added to the system data area. 
Hence, the system areas and the checkpoint area will 
normally consume about 45 tracks of the RAD. (The small- 
est Xerox RAD, .75 megabyte, has 128 tracks.) The only 
other area used by the system is the background temp area. 
The processor that normally requires the largest background 
temp area is Extended Symbol. Extended Symbol normally 
requires the background temp area to be split Into three 
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scratch files, called XI, X2, and X3.^ File XI Is a' 
compressed file and contains the user's source deck 
(about 12 source cards can be compressed into one RAD 
sector). File X2 contains the user's source deck in an en- 
coded form (normally about 36 source cards can be stored 
in one RAD sector on X2). File X3 is only used if the pro- 
gram being assembled contains local symbols. Normally, 
the RAD space required for X3 is insignificant compared 
with XI and X2. Hence, to assemble a 5000-card source 
program, approximately 35 tracks of background temp area 
would be required. Thus, if a user wants to have all the 
system processors and a complete system library stored on 
the RAD, and wants to allocate enough background temp 



area to assemble about a 5000-line source program, approxi- 
mately 80 tracks of the RAD would be used. 



The Job Control Processor will automatically divide the 
total background temp area into three scratch files upon 
encountering an IXSYMBOL command. The total area is 
divided amoung the XT, X2, and X3 files according to the 
following ratios: 

X1:X2:X3 =90: 30: 3 

The user can override these default allocations by inputting 
a ! DEFINE command prior to the IXSYMBOL command. 
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APPENDIX I. CALCULATING THE RBM SIZE 



To calculate the size of RBM (RBM LWA) before a SYSGEN, 
add the base value of F86 or 3980: 

8 X number of I/O channels 

2 X number of definitions in the Public Library 

4 X number of entries in nonresident foreground queue 

4 X number of Master Dictionary entries 

1 X number of entries in Alternate Track Pool 

10 X number of RAD/disk pack devices 

To this figure add the following: 

C4,,,> or 196,, _, cells if a Y response to INC. POWER 
(16) (10) 

ON/OFF 

AD,,,, or 173, ,_, cells if a Y response to INC. MUL/ 
(16) (10) 

DIV SIM. 

BB,,,, or 188,,^, cells if a Y response to INC. M:IOEX 
(16) (10) 



DO,^,, or 216,^- cells if a Y response to INC. CLOCK 

ONE 

10,,,. or 16,,_,. cells if a Y response to INC. DEBUG 
(16) (lU) 

56,.,, or 85,,^, cells if a Y response to INC. MISC. 
2 or 2,._, cells if a Y response to INC. C O. C. 



Add to this amount the number given below (see Table 1-1) 
if the corresponding device type is included in the SYSGEN 
parameter DEVICE FILE INFO: 

To this sum, add tv^^o cells for each background or foreground 
operational label. 

Since SYSGEN attempts to store whatever optional routine 
of tables it can into the unused interrupt locations, the size 
of the unused interrupt region can generally be subtracted 
from this accumulated sum. The size of this area can be 
determined by subtracting the value input for the SYSGEN 
parameter MAX. INT. LOC from 18F(i6) (399(io))- how- 
ever, this figure will be less than the true size of RBM since 
not all of these unused interrupt locations can be used 



Table 1-1. Device Type Table Allocations 



Device 


Size 


First Input 


Additional Inputs 


Hex. 


Dec. 


Hex. 


Dec. 


KP 

LP2 

LPS 

CR4 

CPl 

CP3 

Any magnetic tape 

PT 

PL 

RDtt 

XX 


IF 
IE 
4F 
IB 
IF 
96 
DO 
IF 
19 

6 


31 (required) 

30 

79 

27 

31 
150 
208 

31 

25 

6 


F 

E 

B 

B 

F 

86 

B 

F 

B 

14 

6 


15 
14 
11 
11 
15 
134 
11 
15 
11 
20 
6 


Add two cells to the first input if magnetic tape is BCD. 
The default case for background is nine RD files. 
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APPENDIX J. DEBUG EXPANSION OF INSTRUCTIONS 



EXPANSION OF INSERTED INSTRUCTIONS 



EXPANSION OF MOVED INSTRUCTIONS 



Class 1 instrucHons that are Inserted via the insert (I) com- 
mand are expanded into more than one instruction if desig- 
nated in the op*address form. (Note that expansions of 
indirect instructions are not reentrant. ) 



An instruction that rs moved from the point of insertion to 
the insert block will require expansion if its addressing is 
relative or if it is a register copy instruction in which the 
P register is the source. 



Op is direct (0): 


op 
B 


*$ + 2 
$ + 2 




DATA 


address 


Op is indexed (2): 


op 
B 


*$ + 2, ] 
$ + 2 




DATA 


address 


Op is indirect (4): 


STA 
LDA 


$ + 6 

*$ + 7 




STA 


$+5 




LDA 


$ +3 




op 
B 


*$+3 

$ + 4 




DATA 







DATA 







DATA 


address 


Op is indirect and 


indexed (6^ 


): 




STA 


$ +6 




LDA 


*$ + 7 




STA 


$+5 




LDA 


$ +3 




op 
B 


*$ + 3, 1 

$+4 




DATA 







DATA 







DATA 


address 



Class 2 instructions are expanded as follows: 



op 


$ + 2 


B 


$ +3 


B 


*$+ 1 


DATA 


address 



The relative instructions are expanded the same as the 
inserted instructions discussed in the first part of this 
appendix. In the case of Insert Before (IB) or snap- 
shots, register copy instructions in which P is the source 
and the clear bit is set will be expanded in one of two 
ways: 

1. If the destination is the A register: 



LDA 


$+3 


op 


A, A 


B 


$ + 2 


DATA 


a+ 1 



2. If the destination is not the A register: 



STA 


$ +5 


LDA 


$+5 


op 


A, R 


LDA 


S + 2 


B 


$ + 3 


DATA 





DATA 


a+ 1 



In the above expansions, a is the location (point) of the 
insertion and op has the appropriate settings for the incre- 
mentation and inversion bits. 

Debug has no facility for expanding a copy instruction where 
either (1) the P register Is the source, the A register is the 
destination, and the clear bit Is reset, or (2) the P register 
Is the destination and the clear bit is reset. In this case a 
Debug syntax error is generated. 
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APPENDIX K. DEBUG INSERTION STRUCTURE 



An insertion at location awill result in the following: 
a B */S 

13 DATA X 



y< 



moved instruction expansion if lA command 



inserted instructions or snapshot call code 



moved instruction expansion if IB or snapshot command 



B *$ + 1 

L DATA a+ 1 



where /3 is one of the Debug cells in the zero table and Y is an area in the insertion block. 



164 Appendix K 



APPENDIX L. DEBUG SNAPSHOT CALLING SEQUENCE 



A snapshot inserted at location a will generate the following 
calling sequence (which is inserted in the insertion block 
similar to a Debug IB command): 



a] 


DATA 


D:SNAP 


a2 


DATA 


block 




instruction that was 


at location CL 


entry 


WD 


X'FC (foreground only) 




STA 


*a2 




RCPYI 


P,A 




B 


*a] 




DATA 


a 




DATA 


key 




conditions if any 






DATA 


-1 




message if any 






DATA 


-1 




dumps if any 






. DATA 


-1 



expanded instruction from location a 
B *$ + 1 

DATA a+ 1 



block is the address of the first word of the inser- 

tion block and is used to save the A register, 

key (bits 0-2) designates type of snapshot: setting 
bit designates stepping snapshot; setting bit 1 
designates line printer snapshot output; and setting 
bit 2 designates keyboard control requested. 



message 
any. 



is the string of EBCDIC characters, if 



condition is a string of relational expressions sep- 

arated by logical operators. A relational expres- 
sion occupies three words as follows: 



loc, reg, or constant 


Ml 


M2 




C 


E 


L 


G 


loc, reg, or constant 



dumps 



where 

Ml (bits 0-1) designates the type of 

quantity in the first word: 

00 location 

01 register 
10 constant 

M2 (bits 2-3) designates the type of 

quantity in the third word. 

C (bit 12) designates comparison where 

= arithmetic and 1 = logical. 

E (bit 12) designates equal comparison. 

L (bit 14) designates less than comparison. 

G (bit 15) designates greater than 

comparison. 

A logical operator occupies one word: 

logical or 

1 logical and 

are two-word or three-word items: 

register dump 



1 


T 




register number 


or 





T 




loc 1 


loc 2 



memory dump 



where 

T = 1 designates keyboard/printer and 

line printer output. 

T = designates line printer output. 

A zero register number designates all registers. 
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abort, 12 

abort codes, 151 

ABS control command (Monitor), 9 

Absolute Loader, 9,3,63 

absolute object language, 9 

accounting (clock 1), 4 

accounting file, 14 

active foreground program, viii 

ADD control command (RAD Editor), 86 

address definition, 144 

address literal chain resolution, 145 

AIO receiver, 70,56,31,32,65 

ALL option, 128 

ASSIGN control command (Monitor), 10 

ASSIGN control command (Utility), 97 

ATTEND control command (Monitor), 12 

Automatic Dialing Equipment (ADE), 158 



B 

B debug command, 139 

background, viil 

background abort, 12 

background core allocation, 120 

background jobs, 2, viii, 7 

background restrictions, 7 

background scheduling, 2 

bad tracks, 90 

Basic FORTRAN IV, 6, 18 

Basic FORTRAN IV compiler, 16, 17 

binary object module, 100 

BL opib key-in, 24 

batch processing, viii 

blocked file, 45,87 

blocked RAD files, 51 

blocking buffer, 45 

BLOCK control command (Overlay Loader), 78 

BR, key-in, 24 

BTdn, track key-in, 24 

buffer pool, 45 



C: control command (Monitor), 12 

C:TCB key-in, 24 

CC control command (Monitor), 13 

CC key-in, 24 

CHANGE control command (Utility), 104 

channel time limits, 56 

Character-oriented Communications, 157,6 

check-write operation, 39, 29 

checkpoint, 43, viii, 4, 70 



CLEAR control command (RAD Editor), 90 

clock, 1,4 

COC (see Character Oriented Communications) 

COMMON, 72,77 

completion codes, 54 

compressed EBCDIC file, 13 

compressed f i I es, 8, 39, 8, 40 

compressed records, 36 

CONCORDANCE program 6, 17 

connect line, 55 

context switching, 42 

control command diagnostics, 154 

Control Command Interpreter (see Job Control Processor), 41 

Control Function Processor, 96, 94 

Control Panel Task, 62 

Copy Routine, 97 

COPY control command (Utility), 99 

core memory al location, 118, 117 

core space requirements, 160 

counter interrupt locations, 147 

CP key-in, 24 

cross-reference listing, 6,112 



D debug command, 136 

DTMMDD key-in, 24 

data chaining, 31,56 

data files, 4,3,84 

DB key-in, 24 

DE key-in, 24 

Debug, 135, 6 

Debug commands, 136 

Debug error messages, 140 

Debug expansion, 163 

Debug insertion structure, 164 

Debug snapshot calling sequence, 165 

DEF/REF file, 84 

DEFINE control command (Monitor), 13 

DELETE control command (RAD Editor), 87 

DELETE control command (Utility), 103,105 

device equivalence, 57 

device name, 122, viii 

device unit number, 10 

device order bytes, 59 

device positioning, 44 

device type name, 122,56 

device type table, 121 

device unit number, 1 1, viii, 1 12 

device-file number, 10, viii, 11, 12, 126 

DF key-in, 24 

disk pack, viii 

disconnect line, 55 

displacement chain resolution, 145 

Divide instruction, 62 
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DM key-in, 24 

DR key-in, 25 

DUMP control command (RAD Editor), 89 

DUMP control command (Utility), 100 

Dump Routine, 99 



E 

E debug command, 139 

EBCDIC file, 84 

elapsed time, 4 

end action, 56 

END control command (RAD Editor), 90 

END control command (Overlay Loader), 82 

END control command (Utility), 97 

end module, 143 

end-of-file mark, 16 

EOD control command (Monitor), 13 

EOM key-in, 24,35 

EOT, 39,40 

Extended Symbol, 6, 17 

external interrupts, 63, viii,71 



F key-in, 25 

FBACK control command (Monitor), 13 

FBACK control command (Utility), 96 

FCOPY control command (RAD Editor), 88 

FG key-in, 25, 14 

file allocation, 87 

File Control Table (FCT), 121 

file management, 59 

file name, 4, ix, 1 1 

file positioning, 13 

FIN control command (Monitor), 13 

FL opib key-in, 25 

floating accumulator, 147 

floating flags, 147 

floating-point accumulator, 8 

foreground coding procedures, 71 

foreground initialization, 66 

foreground load, 63 

foreground mailbox, 60 

foreground operational labels, 11 

foreground priority levels, 68,63,64 

foreground programs, 2, ix 

foreground tasks, 2, 7, ix 

foreground updates, 133 

format byte, 38 

FR key-in, 25 

FSKIP control command (Monitor), 13 

FSKIP control command (Utility), 98 



GO file, 18,ix, 15,74, 112 
granule, 58, ix, 32, 34, 48, 72 



H 

H key-in, 25 

hardware requirements, 5 

header word, 142 

HEX control command (Monitor), 14 

hexadecimal corrector cards, 159 

High-speed Line Printer Handler, 117 

HIO, 31 

I 

I debug command, 137 

IDENT control command (Utility), 105 

idle account, 4 

INCLUDE control command (Overlay Loader), 81 

inhibited interrupt, ix 

Input/Output Task, 62 

INSERT control command (Utility), 102, 103 

integral lOP timeout, 147 

Interrupt Switch, 24 

I/O check, 31 

I/O completion codes, 34 

I/O Control Table, 121, ix 

I/O data tables, 31 

I/O initiation, 56 

I/O interrupt, 68 

I/O operations, 56, 68 

I/O priority level, 68 

I/O recovery procedure, 20 

I/O system hardware, 29 

I/O termination, 41 

lOCD, 3,29,31 

IOCS pointers and constants, 147 

lOP watchdog timeout, 61 



J 

JCP (see Job Control Processor) 

job, 7 

job accounting, 4 

JOB control command (Monitor), 14 

Job Control Processor, 9, 16, 18 

JOBC control command (Monitor), 14 

job step, 8, 9 



K Debug command, 139 
K:TCB key-in, 61 
KEY ERROR message, 23 
KP key-in, 25 



L 

LADD control command (RAD Editor), 88 

Lar, dn, wp, key-in, 25 

LB control command (Overlay Loader), 80 
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LCOPY control command (RAD Editor), 89 

LD control command (Overlay Loader), 80 

LDELETE control command (RAD Editor), 89 

LIB control command (Overlay Loader), 78 

Library, 73 

library creation, 133 

library file sizes, 85,86 

library files, 84,4 

library load module, ix 

library update, 133 

LIMIT control command (Monitor), 14 

line mode, 54 

line status, 54 

LIST control command (Utility), 102, 103 

list mode, 102, 103 

load item, 142 

load map, 75, ix 

load module, 10, ix 

load origin, 143 

Loader error messages, 82 

loading foreground, 63 

logical device, ix 

LREPLACE control command (RAD Editor), 88 

LSQUEEZE control command (RAD Editor), 89 



M 

M Debug command, 139 
M:ABORT, 41 
M:ASSIGN, 48,27 
MiCKREST, 43 
M: CLOSE, 45,18,27,38 
M:COC, 53, 157 
MrCTRL, 39,18,27,33 
MrDATIME, 40,27 
MrDEFINE, 47,18,27 
M:DKEYS, 46 
M:DOW, 52,27 
M:EXIT, 42,80 
M.-HEXIN, 42 
M:INHEX, 43 
M:IOEX, 27,117 
MrLOAD, 44,27 
MrOPEN, 45, 27 
MrOPFILE, 51 
M:POP, 50 
MrREAD, 31,33 
M:RES, 50 
M:RSVP, 51,27 
MrSAVE, 42,61,79 
M:SEGLD, 46, 18 
M:TERM, 41, 18 
MrWAIT, 46,27 
M:WRITE, 36,33 
Machine Fault Task, 61 
magnetic tape, 35, 56 
AAagnetic Tape Handler, 1 17 
mailbox, 2,60 
map, 79,89 



MAP control command (RAD Editor), 89 

Mar, dn key-in, 25 

Master Dictionary, 121, 128 

MD control command (Overlay Loader), 81 

memory requirements, 160 

MESSAGE control command (Monitor), 14 

MESSAGE control command (Utility), 96 

ML control command (Overlay Loader), 79 

MODIFY control command (Utility), 102,103 

modify mode, 102, 103 

module directory file, 84 

module file, 84 

Monitor constants, 149 

Monitor control commands, 9 

Monitor messages, 60 

Monitor service routines (see also M: entries), 27,1,8,28,74 

Monitor tasks, 60 

MP control command (Overlay Loader), 79 

MS control command (Overlay Loader), 79 

multiple precision mode, 62 

Multiply instruction, 62 

Multiply/Divide Exception Tasks, 62 

Multiply/Divide simulation, 117 



N 



name definition, 144 
New Line Code, 24 
nonresident foreground, 8, 1 
nonresident foreground programs, 60, ix 



object module, 122, ix, 1 15 

Object Module Editor, 100 

object record format, 141 

OLOAD control command, 77 

OMEDIT control command (Utility), 101,95 

operational label, 10, 155 

operational label table, ix 

operator communication, 20 

operator communication routine, 95 

OPLBS control command (Utility), 98 

OVfile, 18,x,9, 16, 19,74, 112 

OV:LOAD table, 9 

Overlay Loader, 72, 2, 4, 6, 27, 65, 132 

Overlay Loader control commands, 78 

overlay program, x 

override task, 61 



P debug command, 139 
packed-binary mode, 36 
PAUSE control command (Monitor), 14 
PAUSE control command (Utility), 96 
permanent RAD files, 84,3,6 
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PMD control command (Monitor), 14 

physical device, x 

postmortem dump (see PMD), x, 26 

Power Off Routine, 147 

Power Off Task, 61 

Power On Routine, 147 

Power On Task, 60 

Power On/Off, 1 17 

PRESTORE control command (Utility), 97 

primary reference, x 

priority level, 68,2,56 

processor control commands, 16 

processor files, 3 

program, 7 

program deck examples, 112 

protection switches, 5 

Protection Violation Task, 62 

PUBLIB control command (Overlay Loader), 82 

Public Library, 82, 4,72, 1 13, 1 15 

PURGE control command (Monitor), 15 



REL control command (Monitor), 15 

relative location pointer, 144 

relocatable binary program, 15 

relocated load-COMMON base, 143 

relocated load-module base, 142 

repeat load, 142 

resident foreground, 7,60 

resident foreground programs, 60, x 

restart, 43 

RESTORE control command (RAD Editor), 90 

REWIND control command (Monitor), 15 

REWIND (Utility), 97 

rewind off-line, 40 

rewind on-line, 40 

ROOT control command (Overlay Loader), 80 

root segment, 44, 72 

RSKIP control command (Monitor), 13 

RSKIP control command (Utility), 97 



Q debug command, 139 
Q name key-in, 25 
Q:ROC subroutine, 27 



R Debug command, 138 

RAD allocation, 118,6,59,84,124 

RAD/disk pack areas, 3,x, 6, 12, 59, 84, 1 18 

RAD Editor, 84,3,6 

RAD Editor control commands, 86 

RAD Editor error messages, 90 

RAD files, 84,2 

RAD space requirements, 160 

RADEDIT control command, 86 

random files, 58, 13,36,39,57 

RBACK control command (Monitor), 13 

RBACK (Utility), 97 

RBM Control Routine, 7 

RBM Control Task, 8, 12,24,60,62 

RBM size, 162 

RBM Symbol Table, 131 

RBM Zero Table, 147 

RBMOV file, 10 

RCOC Initialization Routine, 55, 157 

record header, 142 

Read Automatic, 35, 36 

Read Backward, 36 

Read Binary, 35, 36 

Real-Time programming, 60 

rebooting system, 133 

RECEDIT control command (Utility), 103 

Record Editor Routine, 102 

record padding, 142 

reentrant routines, 4, x 



S Debug command, 137 

S key-in, 25, 14 

SrLOAD, 9 

SAVE control command (RAD Editor), 90 

secondary reference, 145 

SEG control command (Overlay Loader), 81 

segmented deck examples, 1 14 

semiresident foreground program, 60, x 

SEQEDIT control command (Utility), 105 

SEQUENCE control command (Utility), 106 

Sequence Editor, 104 

sequential files, 57, 15,36,39,40 

SIO, 31 

skip mode, 12 

snapshot dump, 135 

source editing, 102 

Source Input Interpreter, 94 

space file backward, 40 

space file forward, 40 

space record backward, 40 

space record forward, 40 

SQUEEZE control command (RAD Editor), 90,84 

squeezing, 84, 89 

standard constants, 148 

Standard Object Language, 141 

standard system constants and tables, 148, 1 

start module, 143 

SUPPRESS control command (Utility), 106 

SY key-in, 26, 14 

SYSGEN, 117,5 

SYS GEN error messages, 129 

SYSGEN options, 159 

SYSLOAD, 128,117 

SYSLOAD alarms, 133 

system communication, 20 

System Data Area Dictionary, 131 

System Library files, 4,48 

system load, 128, 117 



Index 



169 



Note: For each entry in this index, the number of the most significant page is listed first. Any pages thereafter are listed 
in numberical sequence. 



System Load Processor, 128 
System Processor Dictionary, 131 
system processors, 16, 113 
system RAD, 118, 1 



Utility Program Control Routine, 95 
Utility Program Executive, 94 



T Debug command, 138 

T HRMN key-in, 26 

task, 7 

Task Control Block, 66,xi,7, 79, 147 

TCB (see Task Control Block) 

TCB control command (Overlay Loader), 79 

TEMP control command (Monitor), 15 

Temp Stack, 50, xi, 23,27,68,69 

temporary files, 13, 18 

TIO, 31,30 

TRACKS control command (RAD Editor), 90 



U 



UL key-in, 26 

unblocked file, 13 

UNLOAD control command (Monitor), 16 

UNLOAD control command (Utility), 97 

unrelocated load, 142 

unsolicited key-ins, 24 

UPD option, 131 

user data areas, 3, 12 

User Library files, 4 

Utility control commands, 96 

Utility error messages, 106 

Utility program, 94,6 



VERIFY control command (Utility), 99 



W 



W key-in, 26 

wait condition, 12 

wait instruction, 46 

WEOF control command (Monitor), 16 

WEOF control command (Utility), 97 

Write Binary, 38,39 

Write Direct, 56,63 

Write EBCDIC, 38,39 

Write End-of-File, 37 

Write-End-of-File (see WEOF) 



X debug command, 138 

X key-in, 26 

XED control command (Monitor), 16 

XEQ control command (Monitor), 16 



zero table, 147 
Z key-in, 26 
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